From wesley.george@twcable.com Fri Feb 1 06:36:45 2013 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 B0D7B21E8034 for ; Fri, 1 Feb 2013 06:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=0.434, 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 8RAfi-jEigJ5 for ; Fri, 1 Feb 2013 06:36:45 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3021E8030 for ; Fri, 1 Feb 2013 06:36:44 -0800 (PST) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,579,1355115600"; d="scan'208";a="20564982" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 01 Feb 2013 09:35:11 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 1 Feb 2013 09:36:42 -0500 From: "George, Wes" To: "sidr wg list (sidr@ietf.org)" Date: Fri, 1 Feb 2013 09:36:40 -0500 Thread-Topic: New Version Notification for draft-george-sidr-as-migration-01.txt Thread-Index: Ac4AhjPZ/eWuwOSnSeOJ2duf1/+4IgAAnrWQ Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033DAE6F37@PRVPEXVS15.corp.twcable.com> References: <20130201141236.21468.66765.idtracker@ietfa.amsl.com> In-Reply-To: <20130201141236.21468.66765.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sidr] FW: New Version Notification for draft-george-sidr-as-migration-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: Fri, 01 Feb 2013 14:36:45 -0000 VGhpcyBkcmFmdCBpcyBhIHNpZ25pZmljYW50IHVwZGF0ZSBmcm9tIHRoZSAtMDAgdmVyc2lvbiwg aW5jbHVkaW5nIHRoZSBhZGRpdGlvbiBvZiB0aGUgc29sdXRpb24gd2UgZGlzY3Vzc2VkIGluIEF0 bGFudGEuIFNhbmR5IE11cnBoeSAodGVtcG9yYXJpbHkgZGV2b2lkIG9mIGhlciBmZXN0aXZlIFdH IGNoYWlyIHJlZ2FsaWEpIGhhcyBiZWVuIGFkZGVkIGFzIGEgY28tYXV0aG9yLCB0aGFua3MgdG8g aGVyIGV4dGVuc2l2ZSBjb250cmlidXRpb25zIGluIHRoZSBzb2x1dGlvbiBhbmQgZXhhbXBsZSBz ZWN0aW9uIGFuZCBoZXIgdGhvcm91Z2ggcmV2aWV3IG9mIHRoZSByZXN0LiBJIHRoaW5rIGl0J3Mg Y29tcGxldGUgZW5vdWdoIHRvIHJlcXVlc3Qgc29tZSBhZGRpdGlvbmFsIHJldmlld3MgYW5kIGFk b3B0aW9uIGFzIGEgV0cgZHJhZnQuIEkgd2lsbCBub3RlIHRoYXQgaXQgaXMgY3VycmVudGx5IHN0 aWxsIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQuIEkgZG9uJ3Qga25vdyBpZiBpdCB3b3VsZCBi ZSBtb3JlIGFwcHJvcHJpYXRlIGZvciBpdCB0byBiZSBQUyBnaXZlbiB0aGF0IGl0IGRvZXMgcmVx dWlyZSBzb21lIGNoYW5nZXMgdGhhdCBjb3VsZCBhcmd1YWJseSBiZSBjb25zaWRlcmVkIHByb3Rv Y29sIGNoYW5nZXMuDQoNClRoYW5rcw0KV2VzIEdlb3JnZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXQ0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAwMSwgMjAxMyA5OjEzIEFN DQpUbzogR2VvcmdlLCBXZXMNCkNjOiBzYW5keUB0aXNsYWJzLmNvbQ0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1nZW9yZ2Utc2lkci1hcy1taWdyYXRpb24tMDEu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdlb3JnZS1zaWRyLWFzLW1pZ3Jh dGlvbi0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2VzbGV5IEdl b3JnZSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAg ICAgZHJhZnQtZ2VvcmdlLXNpZHItYXMtbWlncmF0aW9uDQpSZXZpc2lvbjogICAgICAgIDAxDQpU aXRsZTogICAgICAgICAgIEJHUFNlYyBDb25zaWRlcmF0aW9ucyBmb3IgQVMgTWlncmF0aW9uDQpD cmVhdGlvbiBkYXRlOiAgIDIwMTMtMDItMDENCldHIElEOiAgICAgICAgICAgSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE0DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdlb3JnZS1zaWRyLWFzLW1pZ3JhdGlv bi0wMS50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1nZW9yZ2Utc2lkci1hcy1taWdyYXRpb24NCkh0bWxpemVkOiAgICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2VvcmdlLXNpZHItYXMtbWlncmF0aW9uLTAxDQpE aWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWdl b3JnZS1zaWRyLWFzLW1pZ3JhdGlvbi0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgZGlz Y3Vzc2VzIGNvbnNpZGVyYXRpb25zIGFuZCBtZXRob2RzIGZvciBzdXBwb3J0aW5nIGFuZA0KICAg c2VjdXJpbmcgYSBjb21tb24gbWV0aG9kIGZvciBBUy1NaWdyYXRpb24gd2l0aGluIHRoZSBCR1BT ZWMgcHJvdG9jb2wuDQoNCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KVGhpcyBFLW1h aWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2Fi bGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVu dGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENh YmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBv ciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2ht ZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5s YXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUg b3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From eosterweil@verisign.com Sun Feb 3 10:02:45 2013 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 5508A21F8610 for ; Sun, 3 Feb 2013 10:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 MOP7Ysxn9chG for ; Sun, 3 Feb 2013 10:02:44 -0800 (PST) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by ietfa.amsl.com (Postfix) with ESMTP id 31CDC21F8605 for ; Sun, 3 Feb 2013 10:02:43 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKUQ6mQzDx5pSUGhnYH2y2tyOfsCfDKzKg@postini.com; Sun, 03 Feb 2013 10:02:44 PST 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 r13I2eht010474 for ; Sun, 3 Feb 2013 13:02:42 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.107]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Feb 2013 13:02:00 -0500 From: Eric Osterweil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Feb 2013 13:01:25 -0500 Message-Id: <89FE469F-C657-4E38-91F8-F1B3E791BFE5@verisign.com> To: sidr wg Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 03 Feb 2013 18:02:00.0765 (UTC) FILETIME=[909856D0:01CE0238] Subject: [sidr] RPKI operations list? 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: Sun, 03 Feb 2013 18:02:45 -0000 Hey everyone, Is there an operations list somewhere for RPKI repository operations? = We're hoping there's some forum where all of the RIRs and (any other = repo ops) are listening/talking? We've been seeing some anomalies in = the deployed RPKI repositories and we'd like to plug in (especially if = there are already some conversations going about what we've been = seeing). Thanks! Eric= From david.black@emc.com Sun Feb 3 12:55:42 2013 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 C724821F87D9; Sun, 3 Feb 2013 12:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=2.299, BAYES_00=-2.599, GB_I_LETTER=-2, 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 bklcBUlUUe60; Sun, 3 Feb 2013 12:55:41 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1C25021F87D4; Sun, 3 Feb 2013 12:55:40 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r13KtUvx008094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Feb 2013 15:55:32 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sun, 3 Feb 2013 15:55:10 -0500 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r13Kt8Ot005100; Sun, 3 Feb 2013 15:55:08 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Sun, 3 Feb 2013 15:55:08 -0500 From: "Black, David" To: "gen-art@ietf.org" Content-Class: urn:content-classes:message Date: Sun, 3 Feb 2013 15:55:07 -0500 Thread-Topic: Gen-ART review of draft-ietf-sidr-algorithm-agility-11 Thread-Index: AQHN9I+FMi1VHdNSWkquHGET+qZOd5hotufpgAABeIk= Message-ID: <6BE9E091-6BD8-4D6C-941A-7A50128A0773@mimectl> References: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71287E873CF@MX15A.corp.emc.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.3.105.0 Content-Type: multipart/alternative; boundary="_000_6BE9E0916BD84D6C941A7A50128A0773mimectl_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "sidr@ietf.org" Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-11 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: Sun, 03 Feb 2013 20:55:42 -0000 --_000_6BE9E0916BD84D6C941A7A50128A0773mimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One (final, I hope) comment in response to the second last call on this dra= ft. I think publication as a BCP is definitely appropriate, as this draft is en= tirely about a transition process. Thanks, --David ________________________________ From: Roque Gagliano (rogaglia) [rogaglia@cisco.com] Sent: Thursday, January 17, 2013 3:49 AM To: Black, David Cc: Roque Gagliano (rogaglia); Stephen Kent; Sean Turner; gen-art@ietf.org;= sidr@ietf.org; Stewart Bryant (stbryant) Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-11 Thank YOU David for been such a great reviewer. I will solve the Idnits in my working version waiting for other comments du= ring IESG review. Regards, Roque On Jan 17, 2013, at 6:38 AM, "Black, David" wrote: > The -11 version of this draft resolves all of the concerns raised by the > Gen-ART review of the -09 version. I want to thank the authors for the > timely and productive manner in which the review's concerns were addresse= d. > > idnits 2.12.13 found a minor line length problem that can be left to the > RFC Editor to correct. > > Thanks, > --David > >> -----Original Message----- >> From: Black, David >> Sent: Friday, December 28, 2012 3:26 PM >> To: rogaglia@cisco.com; Stephen Kent; Sean Turner; gen-art@ietf.org >> Cc: Black, David; sidr@ietf.org; Stewart Bryant >> Subject: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >> >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> . >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-sidr-algorithm-agility-09 >> Reviewer: David L. Black >> Review Date: December 28, 2012 >> IETF LC End Date: December 14, 2012 >> >> Summary: >> >> This draft is on the right track but has open issues, described in the r= eview. >> >> I apologize for the tardy arrival of this review after the end of IETF L= ast >> Call for this draft - the last few months have been a rather busy time f= or me. >> >> This draft specifies the algorithm transition process for RPKI, which >> entails coordinated issuance of new certificates and other signed produc= ts >> across the collection of RPKI CAs in a fashion that ensures that at leas= t >> one set of signed products is usable at all times. >> >> The draft is generally well-written and clear, but has an unfortunate >> nomenclature change problem that is the primary open issue[*]. >> >> Major issues: >> >> [*] Section 4.7 changes the meaning of the algorithm suite names (A, B >> and C) from prior sections. This also affects Sections 6 and 7. >> I have classified this as a major issue as I believe it introduces >> severe lack of clarity (and potential ambiguity) into the following >> two paragraphs in Section 7: >> >> During Phase 1, a CA that revokes a certificate under Suite A SHOULD >> revoke the corresponding certificate under Suite B, if that >> certificate exists. During Phase 4, a CA that revokes a certificate >> under Suite A SHOULD revoke the corresponding certificate under Suite >> C, if that certificate exists. >> >> During Phase 1, a CA may revoke certificates under Suite B without >> revoking them under Suite A, since the Suite B products are for test >> purposes. During Phase 4 a CA may revoke certificates issued under >> Suite C without revoking them under Suite A, since Suite C products >> are being deprecated. >> >> Despite the use of three letters (A, B and C), there are only two >> algorithm suites involved, and different instances of Suite A refer to >> different algorithm suites. In each paragraph, the first instance of >> "Suite A" refers to the same algorithm suite as "Suite C", and the >> second instance of "Suite A" refers to the same algorithm suite >> as "Suite B". >> >> It would be much better and clearer to not change the meaning of the >> algorithm suite names until the EOL date. In addition, this change >> should enable removal of the Suite C concept from this draft. I >> strongly recommend removing the Suite C concept, as the C-A-B >> chronological order of suite introduction dates seems counter-intuitive. >> >> Minor issues: >> >> Starting in Section 4.3.1, there are a number of uses of "will be" >> (future tense) in the milestone and phase descriptions. All of >> these uses of "will be" should be reviewed to determine whether >> "MUST be" is appropriate, e.g., as appears to be the case for >> this sentence in 4.3.1: >> >> Additionally, the new algorithm transition timeline document will be >> published with the following information: >> >> When "MUST be" is not appropriate, present tense (i.e., "is") is >> preferable. >> >> Nits/editorial: >> >> Abstract: The following two sentences don't quite line up: >> >> The process >> is expected to be completed in a time scale of months or years. >> Consequently, no emergency transition is specified. >> >> Also, section 4.2 indicates that a multi-year transition timeframe >> is expected, which suggests that "months" is not appropriate in >> the abstract. Suggested rephrasing: >> >> The time available to complete the transition process >> is expected to be several years. >> Consequently, no emergency transition process is specified. >> >> Section 2. Introduction: The first sentence in the last paragraph >> mentions a forthcoming BCP on transition timetable. The rest of >> that paragraph implies that the BCP is for a single transition, as >> opposed to being a BCP for transitions in general. It would be >> helpful to clarify that at the start of the paragraph, e.g., >> by adding "For each algorithm transition," to the start of the >> paragraph. >> >> Section 3 Definitions: Is there any concern about possible >> confusion of the use of "Suite B" in this draft with NSA Suite B? >> The draft is clear on what Suite B means for RPKI, but I suspect >> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >> >> Describing Phase 0 as both the steady state of the RPKI and the first >> phase of transition is confusing (e.g., in 4.3). It would be clearer >> if Phase 0 began with publication of the updated RPKI algorithm >> document (Milestone 1) and that the activities that are unchanged >> from steady state were described as not changing in phase 0. >> >> Starting near the end of section 4.3, the three characters >> |-> are used in figures to represent an RPKI hierarchy relationship; >> that relationship should be defined and/or explained before it is used. >> For clarity, I'd suggest swapping the order of the two paragraphs >> above that figure in 4.3 and making the following change at the end >> of the paragraph that is moved down (addition of the word >> "certificate" is the important change): >> >> OLD >> and shows the relationship between three CAs (X, Y, and Z) that form >> a chain. >> NEW >> and shows the relationships among the three CAs (X, Y, and Z) >> that participate in a certificate chain. >> >> Subsequent uses of |-> seemed clear to me. >> >> Section 4.5 Phase 2 says that Suite B product SHOULD be stored at >> independent publication points, but does not make it clear that this >> recommendation applies beyond phase 2. I suggest adding text to >> make that clear - a reference to Section 9 (which is clear about >> this) may be useful as part of that text. >> >> In Section 6, please expand the ROA acronym on first use and consider >> whether it should be defined in Section 3. I'm also assuming that the >> ASN acronym is intended to refer to ASN.1 content; if not, that >> acronym also needs attention. >> >> idnits 2.12.13 found a couple of minor nits: >> >> ** There is 1 instance of too long lines in the document, the longest o= ne >> being 23 characters in excess of 72. >> >> =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keywo= rd, but >> does not include the phrase in its RFC 2119 key words list. >> >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> david.black@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- > --_000_6BE9E0916BD84D6C941A7A50128A0773mimectl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
One (fin= al, I hope) comment in response to the second last call on this draft.
 
I think publication as a= BCP is definitely appropriate, as this draft is entirely about a transitio= n process.
 
Thanks,
--David
 
From: Roque Gagliano (r= ogaglia) [rogaglia@cisco.com]
Sent: Thursday, January 17, 2013 3:= 49 AM
To: Black, David
Cc: Roque Gagliano (rogaglia); S= tephen Kent; Sean Turner; gen-art@ietf.org; sidr@ietf.org; Stewart Bryant (= stbryant)
Subject: Re: Gen-ART review of draft-ietf-sidr-algorith= m-agility-11

Thank YOU David for been such a great reviewer.
<= BR>I will solve the Idnits in my working version waiting for other comments= during IESG review.

Regards,
Roque



On Jan 17, 201= 3, at 6:38 AM, "Black, David" <david.black@emc.com> wrote:

>= ; The -11 version of this draft resolves all of the concerns raised by the<= BR>> Gen-ART review of the -09 version.  I want to thank the author= s for the
> timely and productive manner in which the review's concer= ns were addressed.
>
> idnits 2.12.13 found a minor line lengt= h problem that can be left to the
> RFC Editor to correct.
> > Thanks,
> --David
>
>> -----Original Message--= ---
>> From: Black, David
>> Sent: Friday, December 28, 2= 012 3:26 PM
>> To: rogaglia@cisco.com; Stephen Kent; Sean Turner; = gen-art@ietf.org
>> Cc: Black, David; sidr@ietf.org; Stewart Bryan= t
>> Subject: Gen-ART review of draft-ietf-sidr-algorithm-agility-= 09
>>
>> I am the assigned Gen-ART reviewer for this dra= ft. For background on
>> Gen-ART, please see the FAQ at
>>= ; <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&= gt;.
>>
>> Please resolve these comments along with any = other Last Call comments
>> you may receive.
>>
>&= gt; Document: draft-ietf-sidr-algorithm-agility-09
>> Reviewer: Da= vid L. Black
>> Review Date: December 28, 2012
>> IETF LC= End Date: December 14, 2012
>>
>> Summary:
>> =
>> This draft is on the right track but has open issues, describe= d in the review.
>>
>> I apologize for the tardy arrival= of this review after the end of IETF Last
>> Call for this draft = - the last few months have been a rather busy time for me.
>>
= >> This draft specifies the algorithm transition process for RPKI, wh= ich
>> entails coordinated issuance of new certificates and other = signed products
>> across the collection of RPKI CAs in a fashion = that ensures that at least
>> one set of signed products is usable= at all times.
>>
>> The draft is generally well-written= and clear, but has an unfortunate
>> nomenclature change problem = that is the primary open issue[*].
>>
>> Major issues:>>
>> [*] Section 4.7 changes the meaning of the algorith= m suite names (A, B
>> and C) from prior sections.  This also= affects Sections 6 and 7.
>> I have classified this as a major is= sue as I believe it introduces
>> severe lack of clarity (and pote= ntial ambiguity) into the following
>> two paragraphs in Section 7= :
>>
>>   During Phase 1, a CA that revokes a = certificate under Suite A SHOULD
>>   revoke the corresp= onding certificate under Suite B, if that
>>   certifica= te exists.  During Phase 4, a CA that revokes a certificate
>>= ;   under Suite A SHOULD revoke the corresponding certificate und= er Suite
>>   C, if that certificate exists.
>>=
>>   During Phase 1, a CA may revoke certificates unde= r Suite B without
>>   revoking them under Suite A, sinc= e the Suite B products are for test
>>   purposes. = During Phase 4 a CA may revoke certificates issued under
>> =   Suite C without revoking them under Suite A, since Suite C products<= BR>>>   are being deprecated.
>>
>> Desp= ite the use of three letters (A, B and C), there are only two
>> a= lgorithm suites involved, and different instances of Suite A refer to
&g= t;> different algorithm suites.  In each paragraph, the first insta= nce of
>> "Suite A" refers to the same algorithm suite as "Suite C= ", and the
>> second instance of "Suite A" refers to the same algo= rithm suite
>> as "Suite B".
>>
>> It would be = much better and clearer to not change the meaning of the
>> algori= thm suite names until the EOL date. In addition, this change
>> sh= ould enable removal of the Suite C concept from this draft.  I
>= > strongly recommend removing the Suite C concept, as the C-A-B
>&= gt; chronological order of suite introduction dates seems counter-intuitive= .
>>
>> Minor issues:
>>
>> Starting = in Section 4.3.1, there are a number of uses of "will be"
>> (futu= re tense) in the milestone and phase descriptions.  All of
>>= these uses of "will be" should be reviewed to determine whether
>>= ; "MUST be" is appropriate, e.g., as appears to be the case for
>>= this sentence in 4.3.1:
>>
>>   Additionally,= the new algorithm transition timeline document will be
>> &n= bsp; published with the following information:
>>
>> Whe= n "MUST be" is not appropriate, present tense (i.e., "is") is
>> p= referable.
>>
>> Nits/editorial:
>>
>>= ; Abstract: The following two sentences don't quite line up:
>> >>   The process
>>   is expected to b= e completed in a time scale of months or years.
>>   Con= sequently, no emergency transition is specified.
>>
>> A= lso, section 4.2 indicates that a multi-year transition timeframe
>&g= t; is expected, which suggests that "months" is not appropriate in
>&= gt; the abstract.  Suggested rephrasing:
>>
>> = ;  The time available to complete the transition process
>>&n= bsp;  is expected to be several years.
>>   Consequ= ently, no emergency transition process is specified.
>>
>&g= t; Section 2. Introduction: The first sentence in the last paragraph
>= ;> mentions a forthcoming BCP on transition timetable.  The rest of=
>> that paragraph implies that the BCP is for a single transition= , as
>> opposed to being a BCP for transitions in general.  I= t would be
>> helpful to clarify that at the start of the paragrap= h, e.g.,
>> by adding "For each algorithm transition," to the star= t of the
>> paragraph.
>>
>> Section 3 Definiti= ons: Is there any concern about possible
>> confusion of the use o= f "Suite B" in this draft with NSA Suite B?
>> The draft is clear = on what Suite B means for RPKI, but I suspect
>> that RPKI Suite B= and NSA Suite B are unlikely to match, if ever.
>>
>> D= escribing Phase 0 as both the steady state of the RPKI and the first
>= ;> phase of transition is confusing (e.g., in 4.3).  It would be cl= earer
>> if Phase 0 began with publication of the updated RPKI alg= orithm
>> document (Milestone 1) and that the activities that are = unchanged
>> from steady state were described as not changing in p= hase 0.
>>
>> Starting near the end of section 4.3, the = three characters
>> |-> are used in figures to represent an RPK= I hierarchy relationship;
>> that relationship should be defined a= nd/or explained before it is used.
>> For clarity, I'd suggest swa= pping the order of the two paragraphs
>> above that figure in 4.3 = and making the following change at the end
>> of the paragraph tha= t is moved down (addition of the word
>> "certificate" is the impo= rtant change):
>>
>> OLD
>>   and sho= ws the relationship between three CAs (X, Y, and Z) that form
>>&n= bsp;  a chain.
>> NEW
>>   and shows the r= elationships among the three CAs (X, Y, and Z)
>>   that= participate in a certificate chain.
>>
>> Subsequent us= es of |-> seemed clear to me.
>>
>> Section 4.5 Phase= 2 says that Suite B product SHOULD be stored at
>> independent pu= blication points, but does not make it clear that this
>> recommen= dation applies beyond phase 2.  I suggest adding text to
>> m= ake that clear - a reference to Section 9 (which is clear about
>>= this) may be useful as part of that text.
>>
>> In Sect= ion 6, please expand the ROA acronym on first use and consider
>> = whether it should be defined in Section 3.  I'm also assuming that the=
>> ASN acronym is intended to refer to ASN.1 content; if not, tha= t
>> acronym also needs attention.
>>
>> idnits= 2.12.13 found a couple of minor nits:
>>
>>  ** Th= ere is 1 instance of too long lines in the document, the longest one
>= ;>     being 23 characters in excess of 72.
>&= gt;
>>  =3D=3D The document seems to use 'NOT RECOMMENDED' a= s an RFC 2119 keyword, but
>>     does not inc= lude the phrase in its RFC 2119 key words list.
>>
>> Th= anks,
>> --David
>> -------------------------------------= ---------------
>> David L. Black, Distinguished Engineer
>&= gt; EMC Corporation, 176 South St., Hopkinton, MA  01748
>> += 1 (508) 293-7953          = ;   FAX: +1 (508) 293-7786
>> david.black@emc.com &= nbsp;      Mobile: +1 (978) 394-7754
>> -= ---------------------------------------------------
>


--_000_6BE9E0916BD84D6C941A7A50128A0773mimectl_-- From alexb@ripe.net Tue Feb 5 03:14:38 2013 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 B9FDE21F8635 for ; Tue, 5 Feb 2013 03:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.809 X-Spam-Level: X-Spam-Status: No, score=-0.809 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 BAUHLe0DicBa for ; Tue, 5 Feb 2013 03:14:38 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id E2BCE21F8619 for ; Tue, 5 Feb 2013 03:14:37 -0800 (PST) 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 1U2gTz-0002jZ-DS for sidr@ietf.org; Tue, 05 Feb 2013 12:14:36 +0100 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-135.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1U2gTz-0002qg-9K for sidr@ietf.org; Tue, 05 Feb 2013 12:14:35 +0100 From: Alex Band Content-Type: multipart/alternative; boundary="Apple-Mail=_53FEF3E2-542B-421C-A867-F08577389BAD" Message-Id: Date: Tue, 5 Feb 2013 12:14:34 +0100 To: sidr@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130205 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 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: ddd0bbf11d1e21354000f5f053f5ae69abc1efb1c5c9528665aa7b43891b96df Subject: [sidr] =?windows-1252?q?RIPE_NCC_RPKI_Repository_issue_=96_Sat_2_?= =?windows-1252?q?Feb?= 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, 05 Feb 2013 11:14:38 -0000 --Apple-Mail=_53FEF3E2-542B-421C-A867-F08577389BAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The RIPE NCC RPKI repository became inconsistent and outdated starting = on Saturday, 2 Feb 2013 that lasted for several hours. This was caused = by a problem in our RPKI system that degraded performance to a point = where the publication for all 1300+ Member CAs combined took more than = 24 hours. This meant the CRLs and manifests for some CAs expired before = they republished. The bug that caused the problem has been fixed and we are making sure = the robustness and monitoring of the system is further improved. We are = also taking steps to ensure that the scaling of the system keeps pace = with the adoption by our members.=20 In case you notice a problem with one of our services, please check our = web page with known service and security announcements: http://www.ripe.net/lir-services/service-announcements If you suspect a serious incident or outage with a critical RIPE NCC = service that is not shown here, please contact the RIPE NCC Technical = Emergencies Hotline: http://www.ripe.net/contact/technical-emergency-hotline If you have any questions, please let us know. Cheers, Alex= --Apple-Mail=_53FEF3E2-542B-421C-A867-F08577389BAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The RIPE NCC RPKI repository = became inconsistent and outdated starting on Saturday, 2 Feb 2013 that = lasted for several hours. This was caused by a problem in our RPKI = system that degraded performance to a point where the publication = for all 1300+ Member CAs combined took more than 24 hours. This meant = the CRLs and manifests for some CAs expired before they = republished.

The bug that caused the problem has = been fixed and we are making sure the robustness and monitoring of = the system is further improved. We are also taking steps to ensure that = the scaling of the system keeps pace with the adoption by our = members. 

In case you notice a problem = with one of our services, please check our web page with known service = and security announcements:
http://www= .ripe.net/lir-services/service-announcements

If you suspect a = serious incident or outage with a critical RIPE NCC service that is not = shown here, please contact the RIPE NCC Technical Emergencies = Hotline:
http://ww= w.ripe.net/contact/technical-emergency-hotline

If you have any questions, please let us = know.

Cheers,

Alex
= = --Apple-Mail=_53FEF3E2-542B-421C-A867-F08577389BAD-- From hschiller@google.com Wed Feb 6 07:54:52 2013 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 7B33921F85F3 for ; Wed, 6 Feb 2013 07:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, 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 yEHTmaurlDO6 for ; Wed, 6 Feb 2013 07:54:51 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8E23621F8430 for ; Wed, 6 Feb 2013 07:54:51 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id gg6so1321792lbb.27 for ; Wed, 06 Feb 2013 07:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=29a4BgM1EcUc5rj+mqpunuY77YXynJK9U/S7OIMVeuY=; b=aOlfI9A0GHCZHIJVV2c59voZc96CfinZm08snJaSzxRG2LoEb0gYUovP2XzfdCOVvX XuM+m8Dak8jbFEZY0oX9/k/Yx9wvcOarjIqFs+GCCc5nX8nilHKnhZJFONQ4U2vYHaoy RCKRQ90/C1RLgxAK1Ic1eHxiWsiyKBCDGB7ZTXOHv0NVqKMVGc1PXbzZxEaelpr0+7vm HxyitXxlkEIS/N6/hl4vS/as+ZQL+aWmhSShfiBOc9oiJtAzlsF7W7FA3cPy/IzqQtob PGsoKJYnFvuMSLQMcJPOYaWosvjxCHC/K72tk3npT3iQ/8HJ4x4xn52LpTDmsUqcPJTj 0Y4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=29a4BgM1EcUc5rj+mqpunuY77YXynJK9U/S7OIMVeuY=; b=dBBgIvHxAOaFOc2pbqnzNu7GZBWinvhDK3OFmmD5C52bDURmdt2e0Bg4Yj6p04L9T+ 7v0sqMI+Tij18438WLiUzlrfjrZiGL/wKDqBFnVy/xhCSv3dRRL56WV81SwN2Q1F90oZ 4zhduNv2+y9Gct1RR+JSESdKmLbJdpDmrKq1i7MNpNSgah+HUbHFSiWJsuC0Cjm5y42v cElsTZgYUmEjKzlgR1gEZBoW14z8kqECDjfcwufe0Qa6Tp+yFv+v3mAlDs+G2BZf4DkP 7AkXGuSx9iFYLmTuiOGWLFVwtehGuSrAY2PFtvChoK/G7fYqVn6Gr2Qx4cI7fp5Ofpse m5jg== MIME-Version: 1.0 X-Received: by 10.152.104.199 with SMTP id gg7mr26753632lab.14.1360166089987; Wed, 06 Feb 2013 07:54:49 -0800 (PST) Received: by 10.112.86.104 with HTTP; Wed, 6 Feb 2013 07:54:49 -0800 (PST) Date: Wed, 6 Feb 2013 07:54:49 -0800 Message-ID: From: Heather Schiller To: sidr@ietf.org Content-Type: multipart/alternative; boundary=f46d040890c1a1173604d51058ef X-Gm-Message-State: ALoCoQk9bCJOnh5RCK3bktntEGiBbb2jzpu3xpg8P+bgXKmNk4+Vn0WlZY+pQzFGkqx283yM4zyVo8kDdjXaLkmnBs1ye4zhZB6qb1qrjPYkLThYIgwmu+a2jHgQr8S3Y79xwzWCDSK1vthVCRyw7Fww5tk5g42B45432Z+24Mylhr0vClyylZIl3CMFbPbyWUtDYaEeF1+/ Cc: Sandra.murphy@sparta.com Subject: [sidr] Mozilla RPKI + ROA deployment 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, 06 Feb 2013 15:54:52 -0000 --f46d040890c1a1173604d51058ef Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Stumbled across this... posted 1/15: "A few weeks ago, Mozilla started to use RPKI+ROA, here is a quick introduction. " .... "It=92s so easy that nobody with a RIR account has a valid excuse to not start using it!" https://blog.mozilla.org/it/2013/01/15/rpki-roa/ --Heather --f46d040890c1a1173604d51058ef Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Stumbled across this... posted 1/15:

"A few wee= ks ago, Mozilla started to use RPKI+ROA, here is a quick introduction. &quo= t;

....

"It=92s so easy that nobody with a RIR account h= as a valid excuse to not start using it!"

https://blog.mozilla.org/it/2013/0= 1/15/rpki-roa/

=A0--Heather
--f46d040890c1a1173604d51058ef-- From hschiller@google.com Tue Feb 5 08:08:41 2013 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 9BE8121F88B2 for ; Tue, 5 Feb 2013 08:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, 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 5zn5JZidFW6h for ; Tue, 5 Feb 2013 08:08:41 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 583AA21F8599 for ; Tue, 5 Feb 2013 08:08:23 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id l12so359235lbo.33 for ; Tue, 05 Feb 2013 08:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=FRQGqMZt9yQDfPyRfWMIHvgPd0hV/ZU179DCQbq9VKI=; b=FTzORW5I1sadoA7MJWikmm6KZbpXiCW31ai+ZWns+T7KHpJvrth5XpvqvearsN1Y/u 2YZEi9VMOr/Lg7naCorkCqkHcNrTpocBx+FoBLV8tMVTIfx68YCHzeIluEsr2cvzzM3v tFSF7llVhBF9/N2GjF1JIGmTJt0xPQh9Q0W/QOE+2R3TYnhNX3ZwzKbsRcaVPfvpYXIh iKJeeMAfkgaOl+DVnZMYn876V+++P9zBgz/q+vCmJf+GTAneJKAeJCPGYyDOWDVlpDTu YN/hBrgckXFbKo9gRxLGs0rlBPzgCpDD45BPqDV2tkT6OxNYSdFcFcGpZHa4mtQkqkM+ Qm5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=FRQGqMZt9yQDfPyRfWMIHvgPd0hV/ZU179DCQbq9VKI=; b=PKkFanmNFtzcoS5IK+UhYMTDL5l9wDpThPcIxTJKAIyMGqc2a2iE84gflGcp8DeQYG UBsHxxjgTtNUOBrLBoH9kF4oShtYe9uvGdyNtMXDfACtZKcdhUfIUq6g4LskcbO5AJWu 5PVtanzTi9LbEAhK3T7nwbJFOj1DwpEpCgUJRnP4TrZ9/AC0k9KNzV2UxObC/HuW97I3 9hmhasm8NRtI3B+BlWV1pVe5P8HpENfDDVsdi+H0UB1s470PKYgjShTaHn0VKsEjqGeQ yFNoI1fWXdqn43g7FcfssVqLjLWw2In42VNrz5WsFx7+Gq/igGxEbRqZ7hCFILdSYN0H WmPg== MIME-Version: 1.0 X-Received: by 10.112.43.232 with SMTP id z8mr2363620lbl.135.1360080493986; Tue, 05 Feb 2013 08:08:13 -0800 (PST) Received: by 10.112.5.170 with HTTP; Tue, 5 Feb 2013 08:08:13 -0800 (PST) Date: Tue, 5 Feb 2013 08:08:13 -0800 Message-ID: From: Heather Schiller To: sidr@ietf.org Content-Type: multipart/alternative; boundary=e0cb4efe3400b5c42204d4fc6a07 X-Gm-Message-State: ALoCoQnrhbhA25KL1MKXk8z6NWZDX9aomGJr2iSKVHcusTDNFFKJeDVSJ1Nnku3q95JaPKO0yklyUPQyOu9wO3tWDwDdVb/BBgMOd+Xqn6SscEJqBcw03j+3mfXOgCgQy17OaAQOA77pwVSnSUZi2o6+n5VyEIsqZx4DLceLepf06MXRYVb7qpdA5Vcproet2DcFTAE8nHlU Subject: [sidr] Mozilla RPKI + ROA deployment 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, 06 Feb 2013 17:00:51 -0000 --e0cb4efe3400b5c42204d4fc6a07 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Stumbled across this... posted 1/15: "A few weeks ago, Mozilla started to use RPKI+ROA, here is a quick introduction. " .... "It=92s so easy that nobody with a RIR account has a valid excuse to not start using it!" https://blog.mozilla.org/it/2013/01/15/rpki-roa/ --Heather --e0cb4efe3400b5c42204d4fc6a07 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Stumbled across this... posted 1/15:

"= ;A few weeks ago, Mozilla started to use RPKI+ROA, here is a quick introduc= tion. "

....

"It=92s so easy that nobody with a RIR= account has a valid excuse to not start using it!"

https://bl= og.mozilla.org/it/2013/01/15/rpki-roa/

--Heath= er
--e0cb4efe3400b5c42204d4fc6a07-- From stbryant@cisco.com Wed Feb 6 10:47:14 2013 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 31E5B21F8A48 for ; Wed, 6 Feb 2013 10:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 GebxL6rjsfze for ; Wed, 6 Feb 2013 10:47:13 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C1DC521F8A47 for ; Wed, 6 Feb 2013 10:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7743; q=dns/txt; s=iport; t=1360176433; x=1361386033; h=message-id:date:from:reply-to:mime-version:to:subject; bh=pclJlAoHADYGMHdAeAUGB6Dqz/V33uF9hkInfETxe2g=; b=fmdXSax95p98jntlEFRccgdXzN282t/VJCaIwZ1xSuO4NxkTB5+nL5v5 3pZkzdq472G4KMH4fCp56oiQGfRI8cTiDLw1hGmdBYb6tMD6SCH9sEZwD +O6KpQimw0Xw+Zzy7m0eDgOtdN4VmavbqXD5aTrgESpM5fnMVH8PG71Pr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGmkElGQ/khN/2dsb2JhbABFwEoWc4MePRYYAwIBAgFLAQwIAQGIDaF1mlWRWQOWIZBSgn4 X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; d="scan'208,217";a="150216449" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 06 Feb 2013 18:47:11 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r16IlBBx023922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2013 18:47:11 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r16IlAS8007496; Wed, 6 Feb 2013 18:47:11 GMT Message-ID: <5112A52E.3070202@cisco.com> Date: Wed, 06 Feb 2013 18:47:10 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: sidr wg list , "sidr-chairs@tools.ietf.org" , Adrian Farrel Content-Type: multipart/alternative; boundary="------------070504060706000803070402" Subject: [sidr] RFC5291 - Outbound Route Filter Capability X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 18:47:14 -0000 This is a multi-part message in MIME format. --------------070504060706000803070402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The following errata was filed, but this is beyond the scope of an errata system to address. I think that the right process is for the WG to decide the answer and if necessary for someone to write up a short update to RFC5291 I will close the errata with a pointer to this thread in the SIDR archive. Stewart Errata ID: 3468 *Status: Reported Type: Technical * Reported By: David Lamparter Date Reported: 2013-01-22 Section 5 says: 5. Outbound Route Filtering Capability A BGP speaker that is willing to receive ORF entries from its peer, or a BGP speaker that would like to send ORF entries to its peer, advertises this to the peer by using the Outbound Route Filtering Capability, as described below. The Outbound Route Filtering Capability is a new BGP Capability [BGP-CAP] defined as follows: Capability code: 3 Capability length: variable Capability value: one or more of the entries as shown in Figure 3. +--------------------------------------------------+ | Address Family Identifier (2 octets) | +--------------------------------------------------+ | Reserved (1 octet) | +--------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +--------------------------------------------------+ | Number of ORFs (1 octet) | +--------------------------------------------------+ | ORF Type (1 octet) | +--------------------------------------------------+ | Send/Receive (1 octet) | +--------------------------------------------------+ | ... | +--------------------------------------------------+ | ORF Type (1 octet) | +--------------------------------------------------+ | Send/Receive (1 octet) | +--------------------------------------------------+ Figure 3: Outbound Route Filtering Capability Encoding Notes: RFC5291 does not specify how the ORF capability is supposed to be used in conjunction with multiple enabled AFI/SAFI combinations. The text can be interpreted as either "one capability instance will be sent, carrying multiple blocks as described in Figure 3" or as "the capability will be supplied in more than instance". Note also that RFC3392 [BGP-CAP] Section 4 reads: BGP speakers MAY include more than one instance of a capability (as identified by the Capability Code) with non-zero Capability Length field, but with different Capability Value, and either the same or different Capability Length. Processing of these capability instances is specific to the Capability Code and MUST be described in the document introducing the new capability. Latter description of how multiple instances of the capability are to be processed - albeit relatively obvious - is nowhere to be found in RFC5291. Respectfully requesting a clarification, David Lamparter --------------070504060706000803070402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

The following errata was filed, but this is beyond the scope
of an errata system to address.

I think that the right process is for the WG to decide the answer
and if necessary for someone to write up a short update to
RFC5291

I will close the errata with a pointer to this thread in the
SIDR archive.

Stewart


Errata ID: 3468

Status: Reported
Type: Technical

Reported By: David Lamparter
Date Reported: 2013-01-22

Section 5 says: 

5. Outbound Route Filtering Capability


   A BGP speaker that is willing to receive ORF entries from its peer,
   or a BGP speaker that would like to send ORF entries to its peer,
   advertises this to the peer by using the Outbound Route Filtering
   Capability, as described below.

   The Outbound Route Filtering Capability is a new BGP Capability
   [BGP-CAP] defined as follows:

      Capability code: 3

      Capability length: variable

      Capability value: one or more of the entries as shown in Figure 3.

         +--------------------------------------------------+
         | Address Family Identifier (2 octets)             |
         +--------------------------------------------------+
         | Reserved (1 octet)                               |
         +--------------------------------------------------+
         | Subsequent Address Family Identifier (1 octet)   |
         +--------------------------------------------------+
         | Number of ORFs (1 octet)                         |
         +--------------------------------------------------+
         | ORF Type (1 octet)                               |
         +--------------------------------------------------+
         | Send/Receive (1 octet)                           |
         +--------------------------------------------------+
         | ...                                              |
         +--------------------------------------------------+
         | ORF Type (1 octet)                               |
         +--------------------------------------------------+
         | Send/Receive (1 octet)                           |
         +--------------------------------------------------+

         Figure 3: Outbound Route Filtering Capability Encoding

Notes:

RFC5291 does not specify how the ORF capability is supposed to be used
in conjunction with multiple enabled AFI/SAFI combinations. The text
can be interpreted as either "one capability instance will be sent,
carrying multiple blocks as described in Figure 3" or as "the
capability will be supplied in more than instance".

Note also that RFC3392 [BGP-CAP] Section 4 reads:

BGP speakers MAY include more than one instance of a capability (as
identified by the Capability Code) with non-zero Capability Length
field, but with different Capability Value, and either the same or
different Capability Length. Processing of these capability
instances is specific to the Capability Code and MUST be described in
the document introducing the new capability.

Latter description of how multiple instances of the capability are to be
processed - albeit relatively obvious - is nowhere to be found in RFC5291.


Respectfully requesting a clarification,

David Lamparter

--------------070504060706000803070402-- From morrowc@ops-netman.net Wed Feb 6 10:50:47 2013 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 7857F21F8A45 for ; Wed, 6 Feb 2013 10:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, NO_RELAYS=-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 doU+XJ7UE8eX for ; Wed, 6 Feb 2013 10:50:47 -0800 (PST) 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 D25FB21F86EB for ; Wed, 6 Feb 2013 10:50:45 -0800 (PST) Received: from [IPv6:2620:0:1001:7805:5967:a717:4d8b:cc28] (unknown [IPv6:2620:0:1001:7805:5967:a717:4d8b:cc28]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id E7ADC320090; Wed, 6 Feb 2013 18:50:43 +0000 (UTC) Message-ID: <5112A5FF.7080401@ops-netman.net> Date: Wed, 06 Feb 2013 13:50:39 -0500 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: stbryant@cisco.com References: <5112A52E.3070202@cisco.com> In-Reply-To: <5112A52E.3070202@cisco.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sidr-chairs@tools.ietf.org" , sidr wg list Subject: Re: [sidr] RFC5291 - Outbound Route Filter Capability 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, 06 Feb 2013 18:50:47 -0000 IDR not S-IDR ? (or I missed the tie-in to S-IDR...) On 02/06/2013 01:47 PM, Stewart Bryant wrote: > The following errata was filed, but this is beyond the scope > of an errata system to address. > > I think that the right process is for the WG to decide the answer > and if necessary for someone to write up a short update to > RFC5291 > > I will close the errata with a pointer to this thread in the > SIDR archive. > > Stewart > > > Errata ID: 3468 > > *Status: Reported > Type: Technical > * > Reported By: David Lamparter > Date Reported: 2013-01-22 > > Section 5 says: > > 5. Outbound Route Filtering Capability > > > A BGP speaker that is willing to receive ORF entries from its peer, > or a BGP speaker that would like to send ORF entries to its peer, > advertises this to the peer by using the Outbound Route Filtering > Capability, as described below. > > The Outbound Route Filtering Capability is a new BGP Capability > [BGP-CAP] defined as follows: > > Capability code: 3 > > Capability length: variable > > Capability value: one or more of the entries as shown in Figure 3. > > +--------------------------------------------------+ > | Address Family Identifier (2 octets) | > +--------------------------------------------------+ > | Reserved (1 octet) | > +--------------------------------------------------+ > | Subsequent Address Family Identifier (1 octet) | > +--------------------------------------------------+ > | Number of ORFs (1 octet) | > +--------------------------------------------------+ > | ORF Type (1 octet) | > +--------------------------------------------------+ > | Send/Receive (1 octet) | > +--------------------------------------------------+ > | ... | > +--------------------------------------------------+ > | ORF Type (1 octet) | > +--------------------------------------------------+ > | Send/Receive (1 octet) | > +--------------------------------------------------+ > > Figure 3: Outbound Route Filtering Capability Encoding > > Notes: > > RFC5291 does not specify how the ORF capability is supposed to be used > in conjunction with multiple enabled AFI/SAFI combinations. The text > can be interpreted as either "one capability instance will be sent, > carrying multiple blocks as described in Figure 3" or as "the > capability will be supplied in more than instance". > > Note also that RFC3392 [BGP-CAP] Section 4 reads: > > BGP speakers MAY include more than one instance of a capability (as > identified by the Capability Code) with non-zero Capability Length > field, but with different Capability Value, and either the same or > different Capability Length. Processing of these capability > instances is specific to the Capability Code and MUST be described in > the document introducing the new capability. > > Latter description of how multiple instances of the capability are to be > processed - albeit relatively obvious - is nowhere to be found in RFC5291. > > > Respectfully requesting a clarification, > > David Lamparter > > From stbryant@cisco.com Wed Feb 6 10:53:01 2013 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 991D621F897A for ; Wed, 6 Feb 2013 10:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 UJgmM43xQrZE for ; Wed, 6 Feb 2013 10:53:00 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6203E21F84ED for ; Wed, 6 Feb 2013 10:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3901; q=dns/txt; s=iport; t=1360176780; x=1361386380; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=c/wsnAfH4FkgWfYZ4GCuHlrlCRDJZ5Y3bmtEjpdBZDU=; b=JnEkxwyu+0oZfD6fQmQ9w12CuTO7dAAYnrWaIVejgo5KtmozGspT9O+t 9GC44oXBUh5j7Z4xM8gQ4R2N7qYNkIDZy1gKrpNOApcqfxA3G+2NVb1Na i2oj+gpRFsqRWLczX6YQhls+CcgoML9EJS3B7zxuZQz9JBDKVQzJfcG6V A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACekElGQ/khL/2dsb2JhbABFwEoWc4IfAQEBBDhAARALGAkWDwkDAgECAUUGDQEHAQGIDQy8PpFZA5YhkFKCfg X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; d="scan'208";a="80295788" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 06 Feb 2013 18:52:57 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r16IqvnU015711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2013 18:52:57 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r16Iqr8j007962; Wed, 6 Feb 2013 18:52:54 GMT Message-ID: <5112A685.3070804@cisco.com> Date: Wed, 06 Feb 2013 18:52:53 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Chris Morrow References: <5112A52E.3070202@cisco.com> <5112A5FF.7080401@ops-netman.net> In-Reply-To: <5112A5FF.7080401@ops-netman.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr-chairs@tools.ietf.org" , sidr wg list Subject: Re: [sidr] RFC5291 - Outbound Route Filter Capability X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 18:53:01 -0000 I beg your pardon - I missed the "S" in the WG column. Moving it over there Stewart On 06/02/2013 18:50, Chris Morrow wrote: > IDR not S-IDR ? (or I missed the tie-in to S-IDR...) > > On 02/06/2013 01:47 PM, Stewart Bryant wrote: >> The following errata was filed, but this is beyond the scope >> of an errata system to address. >> >> I think that the right process is for the WG to decide the answer >> and if necessary for someone to write up a short update to >> RFC5291 >> >> I will close the errata with a pointer to this thread in the >> SIDR archive. >> >> Stewart >> >> >> Errata ID: 3468 >> >> *Status: Reported >> Type: Technical >> * >> Reported By: David Lamparter >> Date Reported: 2013-01-22 >> >> Section 5 says: >> >> 5. Outbound Route Filtering Capability >> >> >> A BGP speaker that is willing to receive ORF entries from its peer, >> or a BGP speaker that would like to send ORF entries to its peer, >> advertises this to the peer by using the Outbound Route Filtering >> Capability, as described below. >> >> The Outbound Route Filtering Capability is a new BGP Capability >> [BGP-CAP] defined as follows: >> >> Capability code: 3 >> >> Capability length: variable >> >> Capability value: one or more of the entries as shown in Figure 3. >> >> +--------------------------------------------------+ >> | Address Family Identifier (2 octets) | >> +--------------------------------------------------+ >> | Reserved (1 octet) | >> +--------------------------------------------------+ >> | Subsequent Address Family Identifier (1 octet) | >> +--------------------------------------------------+ >> | Number of ORFs (1 octet) | >> +--------------------------------------------------+ >> | ORF Type (1 octet) | >> +--------------------------------------------------+ >> | Send/Receive (1 octet) | >> +--------------------------------------------------+ >> | ... | >> +--------------------------------------------------+ >> | ORF Type (1 octet) | >> +--------------------------------------------------+ >> | Send/Receive (1 octet) | >> +--------------------------------------------------+ >> >> Figure 3: Outbound Route Filtering Capability Encoding >> >> Notes: >> >> RFC5291 does not specify how the ORF capability is supposed to be used >> in conjunction with multiple enabled AFI/SAFI combinations. The text >> can be interpreted as either "one capability instance will be sent, >> carrying multiple blocks as described in Figure 3" or as "the >> capability will be supplied in more than instance". >> >> Note also that RFC3392 [BGP-CAP] Section 4 reads: >> >> BGP speakers MAY include more than one instance of a capability (as >> identified by the Capability Code) with non-zero Capability Length >> field, but with different Capability Value, and either the same or >> different Capability Length. Processing of these capability >> instances is specific to the Capability Code and MUST be described in >> the document introducing the new capability. >> >> Latter description of how multiple instances of the capability are to be >> processed - albeit relatively obvious - is nowhere to be found in RFC5291. >> >> >> Respectfully requesting a clarification, >> >> David Lamparter >> >> > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From morrowc@ops-netman.net Wed Feb 6 10:54:31 2013 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 D7FF521F84D3 for ; Wed, 6 Feb 2013 10:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, NO_RELAYS=-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 L+QNy41xdeyD for ; Wed, 6 Feb 2013 10:54:25 -0800 (PST) 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 29CC721F8473 for ; Wed, 6 Feb 2013 10:54:23 -0800 (PST) Received: from [IPv6:2620:0:1001:7805:5967:a717:4d8b:cc28] (unknown [IPv6:2620:0:1001:7805:5967:a717:4d8b:cc28]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 7C58B320182; Wed, 6 Feb 2013 18:54:22 +0000 (UTC) Message-ID: <5112A6DD.80105@ops-netman.net> Date: Wed, 06 Feb 2013 13:54:21 -0500 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: stbryant@cisco.com References: <5112A52E.3070202@cisco.com> <5112A5FF.7080401@ops-netman.net> <5112A685.3070804@cisco.com> In-Reply-To: <5112A685.3070804@cisco.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sidr-chairs@tools.ietf.org" , sidr wg list Subject: Re: [sidr] RFC5291 - Outbound Route Filter Capability 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, 06 Feb 2013 18:54:31 -0000 On 02/06/2013 01:52 PM, Stewart Bryant wrote: > I beg your pardon - I missed the "S" in the WG column. > > Moving it over there awesome, thanks! :) it does look like something IDR should poke at though. > Stewart > > On 06/02/2013 18:50, Chris Morrow wrote: >> IDR not S-IDR ? (or I missed the tie-in to S-IDR...) >> >> On 02/06/2013 01:47 PM, Stewart Bryant wrote: >>> The following errata was filed, but this is beyond the scope >>> of an errata system to address. >>> >>> I think that the right process is for the WG to decide the answer >>> and if necessary for someone to write up a short update to >>> RFC5291 >>> >>> I will close the errata with a pointer to this thread in the >>> SIDR archive. >>> >>> Stewart >>> >>> >>> Errata ID: 3468 >>> >>> *Status: Reported >>> Type: Technical >>> * >>> Reported By: David Lamparter >>> Date Reported: 2013-01-22 >>> >>> Section 5 says: >>> >>> 5. Outbound Route Filtering Capability >>> >>> >>> A BGP speaker that is willing to receive ORF entries from its peer, >>> or a BGP speaker that would like to send ORF entries to its peer, >>> advertises this to the peer by using the Outbound Route Filtering >>> Capability, as described below. >>> >>> The Outbound Route Filtering Capability is a new BGP Capability >>> [BGP-CAP] defined as follows: >>> >>> Capability code: 3 >>> >>> Capability length: variable >>> >>> Capability value: one or more of the entries as shown in >>> Figure 3. >>> >>> +--------------------------------------------------+ >>> | Address Family Identifier (2 octets) | >>> +--------------------------------------------------+ >>> | Reserved (1 octet) | >>> +--------------------------------------------------+ >>> | Subsequent Address Family Identifier (1 octet) | >>> +--------------------------------------------------+ >>> | Number of ORFs (1 octet) | >>> +--------------------------------------------------+ >>> | ORF Type (1 octet) | >>> +--------------------------------------------------+ >>> | Send/Receive (1 octet) | >>> +--------------------------------------------------+ >>> | ... | >>> +--------------------------------------------------+ >>> | ORF Type (1 octet) | >>> +--------------------------------------------------+ >>> | Send/Receive (1 octet) | >>> +--------------------------------------------------+ >>> >>> Figure 3: Outbound Route Filtering Capability Encoding >>> >>> Notes: >>> >>> RFC5291 does not specify how the ORF capability is supposed to be used >>> in conjunction with multiple enabled AFI/SAFI combinations. The text >>> can be interpreted as either "one capability instance will be sent, >>> carrying multiple blocks as described in Figure 3" or as "the >>> capability will be supplied in more than instance". >>> >>> Note also that RFC3392 [BGP-CAP] Section 4 reads: >>> >>> BGP speakers MAY include more than one instance of a capability (as >>> identified by the Capability Code) with non-zero Capability Length >>> field, but with different Capability Value, and either the same or >>> different Capability Length. Processing of these capability >>> instances is specific to the Capability Code and MUST be described in >>> the document introducing the new capability. >>> >>> Latter description of how multiple instances of the capability are to be >>> processed - albeit relatively obvious - is nowhere to be found in >>> RFC5291. >>> >>> >>> Respectfully requesting a clarification, >>> >>> David Lamparter >>> >>> >> . >> > > From internet-drafts@ietf.org Thu Feb 7 09:12:54 2013 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 1778C21F8849; Thu, 7 Feb 2013 09:12:54 -0800 (PST) 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 cKJBJ+DdGAGP; Thu, 7 Feb 2013 09:12:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FA221F846E; Thu, 7 Feb 2013 09:12:53 -0800 (PST) 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.37 Message-ID: <20130207171253.18713.18714.idtracker@ietfa.amsl.com> Date: Thu, 07 Feb 2013 09:12:53 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-protocol-mib-05.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, 07 Feb 2013 17:12:54 -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 : Definitions of Managed Objects for the RPKI-Router Proto= col Author(s) : Randy Bush Bert Wijnen Keyur Patel Michael Baer Filename : draft-ietf-sidr-rpki-rtr-protocol-mib-05.txt Pages : 24 Date : 2013-02-07 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the RPKI Router protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpki-rtr-protocol-mib-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Feb 8 07:00:15 2013 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 0537C21F89BA; Fri, 8 Feb 2013 07:00:15 -0800 (PST) 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 7EjI0sdzzRYC; Fri, 8 Feb 2013 07:00:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8144121F8A4F; Fri, 8 Feb 2013 07:00:14 -0800 (PST) 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.37 Message-ID: <20130208150014.11739.57233.idtracker@ietfa.amsl.com> Date: Fri, 08 Feb 2013 07:00:14 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-12.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, 08 Feb 2013 15:00:15 -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 : Algorithm Agility Procedure for RPKI. Author(s) : Roque Gagliano Stephen Kent Sean Turner Filename : draft-ietf-sidr-algorithm-agility-12.txt Pages : 31 Date : 2013-02-08 Abstract: This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-algorithm-agility-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Sandra.Murphy@sparta.com Fri Feb 8 09:30:48 2013 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 63DAA21F8AD8 for ; Fri, 8 Feb 2013 09:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 p5GQzT8inLJo for ; Fri, 8 Feb 2013 09:30:48 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id E6ED121F8A5F for ; Fri, 8 Feb 2013 09:30:47 -0800 (PST) Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id r18HUlx0029360 for ; Fri, 8 Feb 2013 09:30:47 -0800 Received: from Hermes.columbia.ads.sparta.com ([10.62.56.107]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id r18HUlR6014016 for ; Fri, 8 Feb 2013 09:30:47 -0800 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%18]) with mapi id 14.01.0438.000; Fri, 8 Feb 2013 12:30:46 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: important meeting dates for IETF86 Orlando Thread-Index: Ac4GIgeHJqYoD3ieQ/iK1kT9/rQBaw== Date: Fri, 8 Feb 2013 17:30:46 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6582E6E51@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] important meeting dates for IETF86 Orlando 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, 08 Feb 2013 17:30:48 -0000 Here are some important dates for the upcoming meeting. Of particular interest, of course, are the deadlines for internet-draft sub= mission. The deadline for submission of a -00 version is Feb 18, the deadl= ine for subsequent versions is Feb 25. Anyone who thinks they will be submitting a -00 version of a wg draft (some= thing named draft-ietf-sidr-xxxxx) should get in touch with the wg chairs r= eal soon now. The wg chairs must approve the submission of any wg -00 draf= t. =952013-02-11 (Monday): Working Group Chair approval for initial document (= Version -00) submissions appreciated by UTC 24:00. =952013-02-15 (Friday): Final agenda to be published. =952013-02-18 (Monday): Internet Draft Cut-off for initial document (-00) s= ubmission by UTC 24:00, upload using IETF ID Submission Tool. =952013-02-25 (Monday): Internet Draft final submission cut-off by UTC 24:0= 0.=20 =952013-02-27 (Wednesday): Draft Working Group agendas due by UTC 24:00. =952013-03-01 (Friday): Early Bird registration and payment cut-off at UTC = 24:00. =952013-03-04 (Monday): Revised Working Group agendas due by UTC 24:00. =952013-03-04 (Monday): Registration cancellation cut-off at UTC 24:00. --Sandy, speaking as wg chair= From iesg-secretary@ietf.org Fri Feb 8 16:55:07 2013 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 325F421F8C3E; Fri, 8 Feb 2013 16:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 ISxLDgRjBGsG; Fri, 8 Feb 2013 16:55:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA8821F8C5B; Fri, 8 Feb 2013 16:55:06 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130209005506.10026.91747.idtracker@ietfa.amsl.com> Date: Fri, 08 Feb 2013 16:55:06 -0800 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Document Action: 'Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties' to Informational RFC (draft-ietf-sidr-usecases-06.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: Sat, 09 Feb 2013 00:55:07 -0000 The IESG has approved the following document: - 'Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties' (draft-ietf-sidr-usecases-06.txt) as Informational RFC This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-usecases/ Technical Summary This document provides use cases, directions, and interpretations for organizations and relying parties when creating or encountering RPKI object scenarios in the public RPKI. All of the above are discussed here in relation to the Internet routing system. Working Group Summary One reviewer suggested to expand the usecases to cover ongoing work that is out of the scope of the current document. The draft as is has utility at the present time. Future documents can address additional usecases if and when needed. Nothing else to report, apart from the document taking a bit longer in the WG than expected. Document Quality Several prototype implementations (and even commercial for some parts) exist. Reviewers attention is drawn to the Section 1.2 which describes why RFC1918 prefixes are used rather than the RFC5737 prefixes. This was discussed in the Working Group and was the agreed way forward. Personnel Alexey Melnikov is the document shepherd. Stewart Bryant is the Responsible AD. RFC Editor Note In the acknowledgements please s/Stephen Farrel/Stephen Farrell/ From internet-drafts@ietf.org Mon Feb 11 09:33:17 2013 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 E548B21F8996; Mon, 11 Feb 2013 09:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 aDts8XzuGXJG; Mon, 11 Feb 2013 09:33:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7959E21F8938; Mon, 11 Feb 2013 09:33:17 -0800 (PST) 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.37 Message-ID: <20130211173317.7106.25684.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2013 09:33:17 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-protocol-mib-06.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, 11 Feb 2013 17:33:18 -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 : Definitions of Managed Objects for the RPKI-Router Proto= col Author(s) : Randy Bush Bert Wijnen Keyur Patel Michael Baer Filename : draft-ietf-sidr-rpki-rtr-protocol-mib-06.txt Pages : 24 Date : 2013-02-11 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the RPKI Router protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpki-rtr-protocol-mib-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From achi@bbn.com Fri Feb 15 14:19:55 2013 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 3C07E21F85AC for ; Fri, 15 Feb 2013 14:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.522 X-Spam-Level: X-Spam-Status: No, score=-4.522 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] 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 MKgoqlX29kFZ for ; Fri, 15 Feb 2013 14:19:54 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 36FF121F85A1 for ; Fri, 15 Feb 2013 14:19:54 -0800 (PST) Received: from dhcp89-089-010.bbn.com ([128.89.89.10]:61388 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U6TdJ-0008BO-EY for sidr@ietf.org; Fri, 15 Feb 2013 17:19:53 -0500 Message-ID: <511EB481.80400@bbn.com> Date: Fri, 15 Feb 2013 17:19:45 -0500 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: sidr wg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] RPSTIR 0.6 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, 15 Feb 2013 22:19:55 -0000 We've released a new version of the BBN RPKI validator (RPSTIR 0.6) that should be easier to install and use. I've included release notes for both v0.5 and v0.6 in this email. Also, if someone has created a list for RPKI repository operations as Eric Osterweil asked on 2/3, we would certainly be interested in joining/contributing. Feedback is most welcome! -Andrew -------------- Download: https://sourceforge.net/projects/rpstir/ Contact: rpstir-support@bbn.com Subscribe to new release announcements by sending a blank email to rpstir-announce-join@bbn.com. You will need to reply to the confirmation challenge via email, as currently, the confirmation link is inaccessible. RPSTIR 0.6 Release Notes Release 0.6 of the Relying Party Security Technology for Internet Routing (RPSTIR) represents significant improvements in several areas, ranging from user interface to internal code organization. 1. Simplified user interface: a. Operation is simplified to four user-facing commands: rpstir-initialize, rpstir-synchronize, rpstir-rpki-rtr-update, and rpstir-results. b. Configuration parameters are now consolidated into a single config file. c. Logging is now standardized to syslog. 2. The build/installation procedure is faster and makes full use of Autotools. It now aligns with the Filesystem Hierarchy Standard (FHS), so that binaries install by default into /usr/local/bin, configuration files into /usr/local/etc/rpstir/, the local cache of the RPKI into /usr/local/var/cache/rpstir/, and so on. The installation instructions have been improved based on user experience. For Ubuntu, the line-by-line installation walkthrough has been updated to reflect the new installation targets. 3. The code base has undergone significant reorganization; related code has been de-duplicated and pulled into appropriate helper libraries. Self-testing is now stricter when the valgrind memory-checking tool is available. 4. This release includes several improvements and bug fixes for memory leaks, database retrieval errors, and out-of-order insertion of RPKI objects (a bug detected at IETF 85). The code for retrieving trust anchors now implements a limited retry to be more robust when there are connectivity issues. RPSTIR has been updated to work with Cryptlib 3.4.2. RPSTIR 0.5 Release Notes Release 0.5 of the Relying Party Security Technology for Internet Routing (RPSTIR) was a bug fix and optimization release, and included the following changes. 1. Optimized the fetching algorithm to reduce the number of rsync sessions to RPKI repositories. 2. Fixed compatibility issues when fetching from older rsync servers. 3. Fixed support for long (20-octet) serial numbers. Credit to ARIN for reporting the bug. 4. Ensured that RPSTIR instances are cleaned up and do not interfere with future instances. 5. Added a mechanism to notify the user via log when a new version of RPSTIR is available. 6. Added a line-by-line installation walkthrough for Ubuntu. From ietf-ipr@ietf.org Tue Feb 19 11:58:45 2013 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 B829B21F8D9C; Tue, 19 Feb 2013 11:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 y8hHBfXiQHaP; Tue, 19 Feb 2013 11:58:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4413621F8878; Tue, 19 Feb 2013 11:58:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: turners@ieca.com X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130219195844.10623.34903.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2013 11:58:44 -0800 Cc: sidr@ietf.org, Sandra.Murphy@sparta.com, morrowc@ops-netman.net, ipr-announce@ietf.org Subject: [sidr] IPR Disclosure: Certicom Corporation's Statement about IPR related to draft-ietf-sidr-bgpsec-algs-03 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, 19 Feb 2013 19:58:45 -0000 Dear Sean Turner: An IPR disclosure that pertains to your Internet-Draft entitled "BGP Algorithms, Key Formats, & Signature Formats" (draft-ietf-sidr-bgpsec-algs)= was submitted to the IETF Secretariat on 2013-02-19 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1965/). The title of the IPR disclosure is "Certicom Corporation's Statement about IPR related to draft-ietf-sidr-bgps= ec- algs-03.""); The IETF Secretariat From iesg-secretary@ietf.org Wed Feb 20 06:48:03 2013 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 368DA21F87E4; Wed, 20 Feb 2013 06:48:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RICrrBwPkhLY; Wed, 20 Feb 2013 06:48:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D4E21F8816; Wed, 20 Feb 2013 06:48:02 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130220144802.1065.57523.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 06:48:02 -0800 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'Algorithm Agility Procedure for RPKI.' to Best Current Practice (draft-ietf-sidr-algorithm-agility-12.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: Wed, 20 Feb 2013 14:48:03 -0000 The IESG has approved the following document: - 'Algorithm Agility Procedure for RPKI.' (draft-ietf-sidr-algorithm-agility-12.txt) as Best Current Practice This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility/ Technical Summary This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). Working Group Summary During WGLC there was some prolonged discussion on whether IETF is the right body for publishing a set of milestones for different phases of algorithm migration and which other entities should be involved (IANA, NROs, etc.). The issue was discussed and the text was improved in this area. There was also an extended discussion during WGLC on whether top-down migration is the right way to do algorithm migration. I think the WG still supports this approach. Document Quality This document is not specifying a protocol, so there are no implementations. However considering past history in the Security Area with algorithm migration in different protocols, such migration event is quite likely, if RPKI ends up being used for any significant period of time. Personnel Alexey Melnikov is the Document Shepherd. Stewart Bryant is the Responsible Area Director. RFC Editor Note Please change the Intended Status from Proposed Standard to BCP From iesg-secretary@ietf.org Wed Feb 20 06:48:03 2013 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 989C221F8803 for ; Wed, 20 Feb 2013 06:48:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAIwDLtL7ZjP; Wed, 20 Feb 2013 06:48:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BC521F8821; Wed, 20 Feb 2013 06:48:02 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40 X-IETF-Draft-string: draft-ietf-sidr-algorithm-agility X-IETF-Draft-revision: 12 Message-ID: <20130220144802.1065.48860.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 06:48:02 -0800 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'Algorithm Agility Procedure for RPKI.' to Best Current Practice (draft-ietf-sidr-algorithm-agility-12.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 14:48:03 -0000 The IESG has approved the following document: - 'Algorithm Agility Procedure for RPKI.' (draft-ietf-sidr-algorithm-agility-12.txt) as Best Current Practice This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility/ Technical Summary This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). Working Group Summary During WGLC there was some prolonged discussion on whether IETF is the right body for publishing a set of milestones for different phases of algorithm migration and which other entities should be involved (IANA, NROs, etc.). The issue was discussed and the text was improved in this area. There was also an extended discussion during WGLC on whether top-down migration is the right way to do algorithm migration. I think the WG still supports this approach. Document Quality This document is not specifying a protocol, so there are no implementations. However considering past history in the Security Area with algorithm migration in different protocols, such migration event is quite likely, if RPKI ends up being used for any significant period of time. Personnel Alexey Melnikov is the Document Shepherd. Stewart Bryant is the Responsible Area Director. RFC Editor Note Please change the Intended Status from Proposed Standard to BCP From internet-drafts@ietf.org Wed Feb 20 15:06:30 2013 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 B327F21E8037; Wed, 20 Feb 2013 15:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 7BLCEvG+IXTi; Wed, 20 Feb 2013 15:06:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B3521F86E7; Wed, 20 Feb 2013 15:06:29 -0800 (PST) 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.40 Message-ID: <20130220230629.4955.64085.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 15:06:29 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-ops-20.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: Wed, 20 Feb 2013 23:06:30 -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-20.txt Pages : 11 Date : 2013-02-20 Abstract: Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present those which are most critical. It is expected to evolve as RPKI-based origin validation continues to be 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-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-origin-ops-20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Feb 20 15:08:55 2013 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 9302021F85A4; Wed, 20 Feb 2013 15:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 t5iCD09ya0lZ; Wed, 20 Feb 2013 15:08:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5DA21F87AB; Wed, 20 Feb 2013 15:08:55 -0800 (PST) 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.40 Message-ID: <20130220230855.4989.22116.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 15:08:55 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-06.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: Wed, 20 Feb 2013 23:08:55 -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 : Security Requirements for BGP Path Validation Author(s) : Steven M. Bellovin Randy Bush David Ward Filename : draft-ietf-sidr-bgpsec-reqs-06.txt Pages : 8 Date : 2013-02-20 Abstract: This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-reqs-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From morrowc@ops-netman.net Thu Feb 21 20:30:33 2013 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 2368021F8E70 for ; Thu, 21 Feb 2013 20:30:33 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXy3KsFJ+o9J for ; Thu, 21 Feb 2013 20:30:32 -0800 (PST) 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 A65F721F8E6C for ; Thu, 21 Feb 2013 20:30:32 -0800 (PST) Received: from [IPv6:2001:470:e03a:b00b:8d00:b76b:96e1:41d3] (unknown [IPv6:2001:470:e03a:b00b:8d00:b76b:96e1:41d3]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id BB0CB32008F; Fri, 22 Feb 2013 04:30:29 +0000 (UTC) Message-ID: <5126F465.8030005@ops-netman.net> Date: Thu, 21 Feb 2013 23:30:29 -0500 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: sidr wg list , "sidr-chairs@tools.ietf.org" , "sidr-ads@tools.ietf.org" X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013) 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, 22 Feb 2013 04:30:33 -0000 WG folks, As the subject states, let's please start a WGLC poll for the document: draft-ietf-sidr-cps-01 with the abstract: "This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP." So far the authors have made a few revisions, with updates based on comments/feedback, at this time the document has been stable for more than 6 months time, let's move this along if there are no further issues/addendums/questions/appendixes. thanks! -chris co-chair-1-of-3 From internet-drafts@ietf.org Sat Feb 23 07:41:11 2013 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 F04A921F8FA1; Sat, 23 Feb 2013 07:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=0.317, 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 ckhCHEEeUyx1; Sat, 23 Feb 2013 07:41:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8214321F8F87; Sat, 23 Feb 2013 07:41:10 -0800 (PST) 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.40 Message-ID: <20130223154110.5586.21859.idtracker@ietfa.amsl.com> Date: Sat, 23 Feb 2013 07:41:10 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-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: Sat, 23 Feb 2013 15:41:11 -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 : Router Keying for BGPsec Author(s) : Sean Turner Keyur Patel Randy Bush Filename : draft-ietf-sidr-rtr-keying-01.txt Pages : 9 Date : 2013-02-23 Abstract: BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global RPKI (Resource Public Key Infrastructure). This document describes two ways of provisioning public/private keys, router-driven and operator- driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From carlos@lacnic.net Mon Feb 25 12:25:02 2013 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 8FC5D21E809E for ; Mon, 25 Feb 2013 12:25:02 -0800 (PST) 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=[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 L3lumIkV3kHs for ; Mon, 25 Feb 2013 12:25:01 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id E725921E8092 for ; Mon, 25 Feb 2013 12:25:00 -0800 (PST) Received: from europa.local (unknown [200.7.85.163]) by mail.lacnic.net.uy (Postfix) with ESMTP id 873FE308427 for ; Mon, 25 Feb 2013 18:24:51 -0200 (UYST) Message-ID: <512BC89A.1040603@lacnic.net> Date: Mon, 25 Feb 2013 18:24:58 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "sidr@ietf.org" References: <20130225202309.13536.56264.idtracker@ietfa.amsl.com> In-Reply-To: <20130225202309.13536.56264.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <20130225202309.13536.56264.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080606090901030706030005" 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: carlos@lacnic.net Subject: [sidr] Fwd: New Version Notification for draft-rogaglia-sidr-multiple-publication-points-02.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, 25 Feb 2013 20:25:02 -0000 This is a multi-part message in MIME format. --------------080606090901030706030005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Folks, we've submitted a -02 regards ~Carlos -------- Original Message -------- Subject: New Version Notification for draft-rogaglia-sidr-multiple-publication-points-02.txt Date: Mon, 25 Feb 2013 12:23:09 -0800 From: internet-drafts@ietf.org To: carlos@lacnic.net CC: rogaglia@cisco.com, terry.manderson@icann.org A new version of I-D, draft-rogaglia-sidr-multiple-publication-points-02.txt has been successfully submitted by Carlos Martinez and posted to the IETF repository. Filename: draft-rogaglia-sidr-multiple-publication-points Revision: 02 Title: Multiple Repository Publication Points support in the Resource Public Key Infrastructure (RPKI) Creation date: 2013-02-25 Group: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-rogaglia-sidr-multiple-publication-points-02.txt Status: http://datatracker.ietf.org/doc/draft-rogaglia-sidr-multiple-publication-points Htmlized: http://tools.ietf.org/html/draft-rogaglia-sidr-multiple-publication-points-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-rogaglia-sidr-multiple-publication-points-02 Abstract: The Resource Public Key Infrastructure (RPKI) depends on Relying Parties (RP) ability to access its Trust Anchors' certificate specified in the different "Trust Anchor Locator (TAL)" files and the Repository Objects located at the Certificate Authorities (CA) repositories hosted in its respective publication point. This document updates [RFC6490] by allowing multiple URI associated to a single public key in a TAL file and introduces the concept of multiple repository publication point operators for every CA in the RPKI. This document provides also recommendation for the RP behavior when analyzing signed objects that include multiple publications points. The IETF Secretariat --------------080606090901030706030005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Folks,

we've submitted a -02

regards

~Carlos


-------- Original Message --------
Subject: New Version Notification for draft-rogaglia-sidr-multiple-publication-points-02.txt
Date: Mon, 25 Feb 2013 12:23:09 -0800
From: internet-drafts@ietf.org
To: carlos@lacnic.net
CC: rogaglia@cisco.com, terry.manderson@icann.org 


A new version of I-D, draft-rogaglia-sidr-multiple-publication-points-02.txt
has been successfully submitted by Carlos Martinez and posted to the
IETF repository.

Filename:	 draft-rogaglia-sidr-multiple-publication-points
Revision:	 02
Title:		 Multiple Repository Publication Points support in the Resource Public Key Infrastructure (RPKI)
Creation date:	 2013-02-25
Group:		 Individual Submission
Number of pages: 13
URL:             http://www.ietf.org/internet-drafts/draft-rogaglia-sidr-multiple-publication-points-02.txt
Status:          http://datatracker.ietf.org/doc/draft-rogaglia-sidr-multiple-publication-points
Htmlized:        http://tools.ietf.org/html/draft-rogaglia-sidr-multiple-publication-points-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-rogaglia-sidr-multiple-publication-points-02

Abstract:
   The Resource Public Key Infrastructure (RPKI) depends on Relying
   Parties (RP) ability to access its Trust Anchors' certificate
   specified in the different "Trust Anchor Locator (TAL)" files and the
   Repository Objects located at the Certificate Authorities (CA)
   repositories hosted in its respective publication point.  This
   document updates [RFC6490] by allowing multiple URI associated to a
   single public key in a TAL file and introduces the concept of
   multiple repository publication point operators for every CA in the
   RPKI.  This document provides also recommendation for the RP behavior
   when analyzing signed objects that include multiple publications
   points.

                                                                                  


The IETF Secretariat


--------------080606090901030706030005-- From Sandra.Murphy@sparta.com Mon Feb 25 13:04:14 2013 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 8557421E80E1 for ; Mon, 25 Feb 2013 13:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 uFbHfp-jI+WK for ; Mon, 25 Feb 2013 13:03:57 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id D095421E80DB for ; Mon, 25 Feb 2013 13:03:54 -0800 (PST) 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 r1PL3ser002483 for ; Mon, 25 Feb 2013 15:03:54 -0600 Received: from Hermes.columbia.ads.sparta.com ([10.62.56.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r1PL3sv3019727 for ; Mon, 25 Feb 2013 15:03:54 -0600 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%18]) with mapi id 14.02.0247.003; Mon, 25 Feb 2013 16:03:48 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: request for agenda items Thread-Index: Ac4Tm5rJ2QzVI03iTWuu0A/oY7LgWw== Date: Mon, 25 Feb 2013 21:03:47 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F65C22D716@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] request for agenda items 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, 25 Feb 2013 21:04:16 -0000 Any who would like to speak at sidr in the IETF86 meeting in Orlando, pleas= e do send a message to the chairs and/or list.=0A= =0A= --Sandy Murphy, speaking as one of the wg co-chairs= From internet-drafts@ietf.org Mon Feb 25 15:58:33 2013 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 30EFD21E81C0; Mon, 25 Feb 2013 15:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 SgD+OsAjIV32; Mon, 25 Feb 2013 15:58:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E12721F8495; Mon, 25 Feb 2013 15:58:06 -0800 (PST) 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.40 Message-ID: <20130225235806.9052.53684.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 15:58:06 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-07.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, 25 Feb 2013 23:58:33 -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 Protocol Specification Author(s) : Matthew Lepinski Filename : draft-ietf-sidr-bgpsec-protocol-07.txt Pages : 35 Date : 2013-02-25 Abstract: This document describes BGPSEC, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems through which a BGP update message passes. BGPSEC is implemented via a new optional non-transitive BGP path attribute that carries a digital signature produced by each autonomous system that propagates the update message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-protocol-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mlepinski.ietf@gmail.com Mon Feb 25 16:04:33 2013 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 AD4FB21F873D for ; Mon, 25 Feb 2013 16:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 zBYq9jRGz9ym for ; Mon, 25 Feb 2013 16:04:32 -0800 (PST) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id AADE321F8444 for ; Mon, 25 Feb 2013 16:04:32 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id nd7so1204339qeb.38 for ; Mon, 25 Feb 2013 16:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=PEGK0DtpPLXOgwdOxWntQen+zFxQMWPuvgv4ukj3EcE=; b=APy6I9C/9iiQ30skeor8ohc4q8muJ2tq1/neBHC6je+YqZGHNUh5ikJt3q3ftj5r4U +210IgpO/DikSxUNvmgOzrDU6Mg1cr0YNGpc1wAkBqmXD/VItzch4laneV9eG5iT8qXF aIBcKgKs5f9qs2d1kel3kk+RZE5KkqU6ywcJDeTa3YYX8a6ukPVqdTMAs3S3cqt8BjmZ +COhuyV5dupuRjySXwRbEW7It0Us3lgsOR7emhWysvh3B3qk6g3Ej6HkxsvoP2fD3g4z 48yH1uBymwKYfm2gYrouGi4KbPEQKW9XCvwgh0c712QmLqRhaXjxr9/liutqR1OlKziL JPyQ== MIME-Version: 1.0 X-Received: by 10.49.37.226 with SMTP id b2mr16749945qek.31.1361837072201; Mon, 25 Feb 2013 16:04:32 -0800 (PST) Received: by 10.49.129.196 with HTTP; Mon, 25 Feb 2013 16:04:32 -0800 (PST) In-Reply-To: <20130225235806.9052.53684.idtracker@ietfa.amsl.com> References: <20130225235806.9052.53684.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 19:04:32 -0500 Message-ID: From: Matthew Lepinski To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nomcom-chair@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:04:33 -0000 New version of draft-ietf-bpgsec-protocol. The only changes that I made were in Section 2 (negotiation of BGPSEC). The previous version defined two separate capabilities (a Send capability and a Receive capability). The authors received feedback that it was important not to be wasteful of BGP capability numbers and therefore the two capabilities were merged into a single BGPSEC capability. On Mon, Feb 25, 2013 at 6:58 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : BGPSEC Protocol Specification > Author(s) : Matthew Lepinski > Filename : draft-ietf-sidr-bgpsec-protocol-07.txt > Pages : 35 > Date : 2013-02-25 > > Abstract: > This document describes BGPSEC, an extension to the Border Gateway > Protocol (BGP) that provides security for the path of autonomous > systems through which a BGP update message passes. BGPSEC is > implemented via a new optional non-transitive BGP path attribute that > carries a digital signature produced by each autonomous system that > propagates the update message. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-07 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From waehlisch@ieee.org Tue Feb 26 17:14:57 2013 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 AB01021F86C1 for ; Tue, 26 Feb 2013 17:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 hzgcxLlyZi4I for ; Tue, 26 Feb 2013 17:14:57 -0800 (PST) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id B48E321F86B2 for ; Tue, 26 Feb 2013 17:14:56 -0800 (PST) Envelope-to: sidr@ietf.org Received: from rrcs-67-52-140-5.west.biz.rr.com ([67.52.140.5] helo=mw-PC.safetynetaccess.com) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UAVbi-0002Il-NC for sidr@ietf.org; Wed, 27 Feb 2013 02:14:55 +0100 Date: Tue, 26 Feb 2013 17:14:50 -0800 (Pacific Normalzeit (Mexiko)) From: Matthias Waehlisch To: sidr wg Message-ID: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Subject: [sidr] RPKI Validator for Firefox 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, 27 Feb 2013 01:14:57 -0000 Hi all, just for fun and inspired by Mozilla RPKI trials, we implemented a Firefox Add-on that provides validation result of the web server's prefix. * https://addons.mozilla.org/addon/rpki-validator/ IP address to prefix mapping is performed by Team Cymru Service, prefix validation is based on the RTRlib. If you like it, let me know ;). See you in Orlando matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From aservin@lacnic.net Tue Feb 26 17:42:11 2013 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 8F6A221F8633 for ; Tue, 26 Feb 2013 17:42:11 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+6+2J6762g3 for ; Tue, 26 Feb 2013 17:42:10 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE6D21F862E for ; Tue, 26 Feb 2013 17:42:10 -0800 (PST) Received: from 35.144.dhcp.conference.apricot.net (unknown [IPv6:2001:df9:0:4015:4873:7069:cfb5:4f7]) by mail.lacnic.net.uy (Postfix) with ESMTP id 7C8AF308427 for ; Tue, 26 Feb 2013 23:42:00 -0200 (UYST) Message-ID: <512D646C.9020800@lacnic.net> Date: Wed, 27 Feb 2013 09:42:04 +0800 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Subject: Re: [sidr] RPKI Validator for Firefox 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, 27 Feb 2013 01:42:11 -0000 Very nice! But it is not working properly, :( It says that my prefix is unknown when it is valid according to my validation: http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.3.12.0/22/ (www.lacnic.net) Does Team Cymru Service has all the TALs updated? Regards as On 27/02/2013 09:14, Matthias Waehlisch wrote: > Hi all, > > just for fun and inspired by Mozilla RPKI trials, we implemented a > Firefox Add-on that provides validation result of the web server's > prefix. > > * https://addons.mozilla.org/addon/rpki-validator/ > > IP address to prefix mapping is performed by Team Cymru Service, > prefix validation is based on the RTRlib. If you like it, let me know > ;). > > > See you in Orlando > matthias > From pmohapat@cisco.com Wed Feb 27 10:51:38 2013 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 A31C521F8A55 for ; Wed, 27 Feb 2013 10:51:38 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-85WcE2Bgl2 for ; Wed, 27 Feb 2013 10:51:36 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9B02621F8A53 for ; Wed, 27 Feb 2013 10:51:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=114; q=dns/txt; s=iport; t=1361991096; x=1363200696; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Y+hQpXXSR8Hay7kpqeHM0XW/EBiWzmB5KRGEQYb4DdE=; b=IGKWyCaqvUi60zyo5IpSwGyuR+QHWAFrhEF+fhkIp4ALkGK/7kH9JnNd Npfx82yWUFZNYqwhBZRIYNgi3/kGhP4vi6EOIboZsjUoFYCmpMrDImX1v cYX9xIvsfuN8NWrTem3kYVAdZRl4Eq8p9ekIHdOTwua1ItMXfYdV0n2N0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALZULlGtJV2Z/2dsb2JhbABFwiZ8FnOCIQEEOlEBCCIUQiUCBAEaiAvCBo5jOIJfYQOnK4MIgWskGA X-IronPort-AV: E=Sophos;i="4.84,750,1355097600"; d="scan'208";a="181879363" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 27 Feb 2013 18:51:36 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1RIpah1006912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Feb 2013 18:51:36 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 12:51:35 -0600 From: "Pradosh Mohapatra (pmohapat)" To: Matthias Waehlisch , sidr wg Thread-Topic: [sidr] RPKI Validator for Firefox Thread-Index: AQHOFIfe5scEDezozE+cYIKy+I18L5iN7FWA Date: Wed, 27 Feb 2013 18:51:34 +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.3.1.130117 x-originating-ip: [10.21.101.197] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] RPKI Validator for Firefox 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, 27 Feb 2013 18:51:38 -0000 > >prefix validation is based on the RTRlib. If you like it, let me know >;). I like it ;-) Thank you! From carlosm3011@gmail.com Wed Feb 27 11:03:59 2013 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 0E5FC21F89B2 for ; Wed, 27 Feb 2013 11:03:59 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YuVK3RYDtXO for ; Wed, 27 Feb 2013 11:03:58 -0800 (PST) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 387A021F8833 for ; Wed, 27 Feb 2013 11:03:58 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id m1so960567ves.36 for ; Wed, 27 Feb 2013 11:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Q2RHIvbAUXwgEwouH65QkXsNtX0wcy4lRG7fyER2EyI=; b=WMlF5n/UbZ+wIlvEVxzyvt3oAaTZHF1LtSXM5UA4WyFXE+Y5TNGaKhJ5ckrkclQ2mJ HjlP31eYsg/28bNguW3sPdKtZifZMR6eD9YsvQBdoBbNP3Ow5WE+auz4GOcVK59pkWeW i42ZgFQNmcRokVgo4lOdeqQP/vjC4KNtvu1xnoG/tkc3zMjWqgTXb/RDLiTQx6m61lkB AQUzgypiutaWlMOJ2rq0CigUa3IE9ymVGGcFOY8qQZvIFANvySyhuJFJDhlw1B2TtCel oCur1lg31rDlzZxjMjhgf0wKiUuy2WK9AzlR+jukEA8bqaEl4b214rMAcGnwLJPdajcT FmwA== X-Received: by 10.52.23.38 with SMTP id j6mr1131957vdf.121.1361991837719; Wed, 27 Feb 2013 11:03:57 -0800 (PST) Received: from ?IPv6:2001:13c7:7001:5128:65ba:a38f:bf3a:872d? ([2001:13c7:7001:5128:65ba:a38f:bf3a:872d]) by mx.google.com with ESMTPS id i17sm1287513vdj.1.2013.02.27.11.03.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 11:03:56 -0800 (PST) Message-ID: <512E5898.3080709@gmail.com> Date: Wed, 27 Feb 2013 17:03:52 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Matthias Waehlisch References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr wg Subject: Re: [sidr] RPKI Validator for Firefox 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: Wed, 27 Feb 2013 19:03:59 -0000 I definitely like it. On 2/26/13 11:14 PM, Matthias Waehlisch wrote: > Hi all, > > just for fun and inspired by Mozilla RPKI trials, we implemented a > Firefox Add-on that provides validation result of the web server's > prefix. > > * https://addons.mozilla.org/addon/rpki-validator/ > > IP address to prefix mapping is performed by Team Cymru Service, > prefix validation is based on the RTRlib. If you like it, let me know > ;). > > > See you in Orlando > matthias > From carlosm3011@gmail.com Wed Feb 27 11:39:12 2013 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 8E5B621F8AFB for ; Wed, 27 Feb 2013 11:39:12 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4piG-Mq41Pl for ; Wed, 27 Feb 2013 11:39:11 -0800 (PST) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id D537121F8A8F for ; Wed, 27 Feb 2013 11:39:10 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id 15so991204vea.14 for ; Wed, 27 Feb 2013 11:39:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R+bTrFDtPfgo8Ty5wljVTcDQGGxWeWczvtRRpr7uKF8=; b=oaY4FmEveSWs0ACrOVKLAKhBGtGxb7J+VtB+yJmusnPF/5g7wagkJpn0zSDeA6KU3z skmUql4RBBZq62blC/jAcJ2QPIPLGZxkdYh7W8SmzQE5ml9wjUGzlq6UkGYqiuYNMw4b twPt6J7Eokp4mXn5hoKQh8O4/h05CWyMlD1JPZj27dRejqsbq+dzs8bmWFEpJNhqiUOK NI3Rqz75mTsioGNAgYzxZUBBgsgjanR33AyHHr/4rCMVToHsRsKWF8QINDT2Di+gf/fE bHlWE7NMJmOJ7GR9Xb+wTmRFF4+hlXiWfkbQy4Y1O/z8H+18L+8ymCU6NomJsPOl/wF/ 2YWA== X-Received: by 10.52.93.235 with SMTP id cx11mr1161152vdb.51.1361993950254; Wed, 27 Feb 2013 11:39:10 -0800 (PST) Received: from [200.7.85.156] ([200.7.85.156]) by mx.google.com with ESMTPS id u5sm1331417vef.0.2013.02.27.11.39.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 11:39:08 -0800 (PST) Message-ID: <512E60D9.2010308@gmail.com> Date: Wed, 27 Feb 2013 17:39:05 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Arturo Servin References: <512D646C.9020800@lacnic.net> In-Reply-To: <512D646C.9020800@lacnic.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] RPKI Validator for Firefox 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: Wed, 27 Feb 2013 19:39:12 -0000 Yup, LACNIC's website resides on a 'valid' prefix. I'm trying other prefixes from our network and they all appear as 'not-found'. Matthias, I'd love to help you troubleshoot the issue. You can contact me on private if you prefer. regards ~Carlos On 2/26/13 11:42 PM, Arturo Servin wrote: > > Very nice! > > But it is not working properly, :( > > It says that my prefix is unknown when it is valid according to my > validation: > > http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.3.12.0/22/ > > (www.lacnic.net) > > Does Team Cymru Service has all the TALs updated? > > Regards > as > > On 27/02/2013 09:14, Matthias Waehlisch wrote: >> Hi all, >> >> just for fun and inspired by Mozilla RPKI trials, we implemented a >> Firefox Add-on that provides validation result of the web server's >> prefix. >> >> * https://addons.mozilla.org/addon/rpki-validator/ >> >> IP address to prefix mapping is performed by Team Cymru Service, >> prefix validation is based on the RTRlib. If you like it, let me know >> ;). >> >> >> See you in Orlando >> matthias >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Wed Feb 27 12:10:14 2013 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 4C03521F88D6 for ; Wed, 27 Feb 2013 12:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 MliSLmZ6Q-kK for ; Wed, 27 Feb 2013 12:10:13 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A63EE21F88C1 for ; Wed, 27 Feb 2013 12:10:13 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UAnKN-00072v-VQ; Wed, 27 Feb 2013 20:10:12 +0000 Date: Thu, 28 Feb 2013 04:10:10 +0800 Message-ID: From: Randy Bush To: Matthias Waehlisch 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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg Subject: Re: [sidr] RPKI Validator for Firefox 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, 27 Feb 2013 20:10:14 -0000 how do i specify my TAL set? randy From waehlisch@ieee.org Wed Feb 27 12:14:16 2013 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 4E9DF21F88ED for ; Wed, 27 Feb 2013 12:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 XnT15NCKf7dg for ; Wed, 27 Feb 2013 12:14:15 -0800 (PST) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id 48C9B21F86D2 for ; Wed, 27 Feb 2013 12:14:15 -0800 (PST) Envelope-to: sidr@ietf.org Received: from rrcs-67-52-140-5.west.biz.rr.com ([67.52.140.5] helo=mw-PC.safetynetaccess.com) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UAnOH-0001bS-F1; Wed, 27 Feb 2013 21:14:14 +0100 Date: Wed, 27 Feb 2013 12:14:07 -0800 (Pacific Normalzeit (Mexiko)) From: Matthias Waehlisch To: Randy Bush In-Reply-To: Message-ID: References: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: sidr wg Subject: Re: [sidr] RPKI Validator for Firefox 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, 27 Feb 2013 20:14:16 -0000 On Thu, 28 Feb 2013, Randy Bush wrote: > how do i specify my TAL set? > future work ;) ... actually, I would more see the question: "how to specify my cache server". Is this of interest? Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From randy@psg.com Wed Feb 27 12:17:22 2013 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 7ADE821F884A for ; Wed, 27 Feb 2013 12:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 eYENMk9J8+W9 for ; Wed, 27 Feb 2013 12:17:22 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id EBAB721F86D2 for ; Wed, 27 Feb 2013 12:17:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UAnRJ-00074U-2q; Wed, 27 Feb 2013 20:17:21 +0000 Date: Thu, 28 Feb 2013 04:17:19 +0800 Message-ID: From: Randy Bush To: Matthias Waehlisch 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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg Subject: Re: [sidr] RPKI Validator for Firefox 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, 27 Feb 2013 20:17:22 -0000 >> how do i specify my TAL set? > future work ;) ... actually, I would more see the question: "how to > specify my cache server". Is this of interest? that would also solve my need randy From eosterweil@verisign.com Wed Feb 27 12:20:00 2013 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 49FA721F8528 for ; Wed, 27 Feb 2013 12:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 Gqoch1-ZPm1h for ; Wed, 27 Feb 2013 12:19:59 -0800 (PST) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 9201221F857C for ; Wed, 27 Feb 2013 12:19:59 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUS5qbOj5QO97pwZMgdBpvRW6teyF5792@postini.com; Wed, 27 Feb 2013 12:19:59 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r1RKJt0X010869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Feb 2013 15:19:55 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 27 Feb 2013 15:19:54 -0500 From: "Osterweil, Eric" To: Randy Bush Thread-Topic: [sidr] RPKI Validator for Firefox Thread-Index: AQHOFIfflO3Q8OMm7Ee1xzwg6r91xpiOd6UAgAABGoCAAADlgP//rOgC Date: Wed, 27 Feb 2013 20:19:54 +0000 Message-ID: <4BBF3947-AADA-4CE7-A4B5-6DE859FDFE3E@verisign.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg Subject: Re: [sidr] RPKI Validator for Firefox 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, 27 Feb 2013 20:20:00 -0000 You might also check out the RPKI update Twitter feed @RPKIUpdateBot I think there are something like 5k tweets now... Eric Sent from my iPhone On Feb 27, 2013, at 12:17 PM, "Randy Bush" wrote: >>> how do i specify my TAL set? >> future work ;) ... actually, I would more see the question: "how to >> specify my cache server". Is this of interest? >=20 > that would also solve my need >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From achi@bbn.com Wed Feb 27 12:30:29 2013 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 6DA5D21F8922 for ; Wed, 27 Feb 2013 12:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.561 X-Spam-Level: X-Spam-Status: No, score=-5.561 tagged_above=-999 required=5 tests=[AWL=1.038, 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 u237wxMM1wTe for ; Wed, 27 Feb 2013 12:30:28 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A245D21F88D1 for ; Wed, 27 Feb 2013 12:30:28 -0800 (PST) Received: from dhcp89-089-010.bbn.com ([128.89.89.10]:50470 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UAndt-000IDo-K0; Wed, 27 Feb 2013 15:30:21 -0500 Message-ID: <512E6CDA.1040908@bbn.com> Date: Wed, 27 Feb 2013 15:30:18 -0500 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Matthias Waehlisch References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg Subject: Re: [sidr] RPKI Validator for Firefox 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, 27 Feb 2013 20:30:29 -0000 Neat plugin. It will be fun to see more green indicators as people issue ROAs for their space. On 2/27/2013 3:14 PM, Matthias Waehlisch wrote: > future work ;) ... actually, I would more see the question: "how to > specify my cache server". Is this of interest? Definitely. Also, since Firefox doesn't know the origin AS for the web page it just retrieved, are you using the Team Cymru service to map IP to AS? (http://www.team-cymru.org/Services/ip-to-asn.html) Andrew From ietf-ipr@ietf.org Wed Feb 27 13:17:23 2013 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 ED90F21F8942; Wed, 27 Feb 2013 13:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.41 X-Spam-Level: X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 ivCtNK+m4KAC; Wed, 27 Feb 2013 13:17:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC1E21F88A9; Wed, 27 Feb 2013 13:17:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: turners@ieca.com X-Test-IDTracker: no X-IETF-IDTracker: 4.40p1 Message-ID: <20130227211722.405.32695.idtracker@ietfa.amsl.com> Date: Wed, 27 Feb 2013 13:17:22 -0800 Cc: sidr@ietf.org, Sandra.Murphy@sparta.com, morrowc@ops-netman.net, ipr-announce@ietf.org Subject: [sidr] IPR Disclosure: Certicom Corporation's Statement about IPR related to draft-ietf-sidr-bgpsec-algs-03 (2) 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, 27 Feb 2013 21:17:23 -0000 Dear Sean Turner: An IPR disclosure that pertains to your Internet-Draft entitled "BGP Algorithms, Key Formats, & Signature Formats" (draft-ietf-sidr-bgpsec-algs)= was submitted to the IETF Secretariat on 2013-02-20 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1967/). The title of the IPR disclosure is "Certicom Corporation's Statement about IPR related to draft-ietf-sidr-bgps= ec- algs-03 (2).""); The IETF Secretariat From andree@toonk.nl Wed Feb 27 14:19:04 2013 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 23BED21F87BA for ; Wed, 27 Feb 2013 14:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_65=0.6] 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 notK9S0wPCfA for ; Wed, 27 Feb 2013 14:19:03 -0800 (PST) Received: from blurp.toonk.nl (cl-1502.ams-04.nl.sixxs.net [IPv6:2001:960:2:5dd::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B69521F84F8 for ; Wed, 27 Feb 2013 14:19:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blurp.toonk.nl (Postfix) with ESMTP id 5113226410E for ; Wed, 27 Feb 2013 23:18:58 +0100 (CET) X-Virus-Scanned: amavisd-new at blurp.toonk.nl Received: from blurp.toonk.nl ([127.0.0.1]) by localhost (blurp.toonk.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBGIM2CXKz0a for ; Wed, 27 Feb 2013 23:18:55 +0100 (CET) Received: from andree-0160.local (unknown [67.215.89.38]) by blurp.toonk.nl (Postfix) with ESMTPSA id E86252640AC for ; Wed, 27 Feb 2013 23:18:54 +0100 (CET) Message-ID: <512E8657.7000904@toonk.nl> Date: Wed, 27 Feb 2013 14:19:03 -0800 From: Andree Toonk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: sidr@ietf.org References: <512E6CDA.1040908@bbn.com> In-Reply-To: <512E6CDA.1040908@bbn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] RPKI Validator for Firefox 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, 27 Feb 2013 22:19:04 -0000 .-- My secret spy satellite informs me that at 2013-02-27 12:30 PM Andrew Chi wrote: > Also, since Firefox doesn't know the origin AS for the web page it just > retrieved, are you using the Team Cymru service to map IP to AS? > (http://www.team-cymru.org/Services/ip-to-asn.html) If the plugin using whois to do this, then you can also do it in one query: Easy to parse: whois -h whois.bgpmon.net " -m 200.3.12.0/22" BGP Prefix|CC|Origin AS| Origin AS Name| Prefix Description|RPKI status|First seen|Last seen|#peers 200.3.12.0/22|UY|28001|LACNIC - Latin American and Caribbean IP address|LACNIC|ROA validation successful|2011-10-19|2013-02-27|152 Or more verbose: whois -h whois.bgpmon.net 200.3.12.0/22 Prefix: 200.3.12.0/22 Prefix description: LACNIC Country code: UY Origin AS: 28001 Origin AS Name: LACNIC - Latin American and Caribbean IP address RPKI status: ROA validation successful First seen: 2011-10-19 Last seen: 2013-02-27 Seen by #peers: 152 Cheers, Andree From waehlisch@ieee.org Wed Feb 27 14:27:03 2013 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 765B921F854C for ; Wed, 27 Feb 2013 14:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 psE+8ZNiaGAt for ; Wed, 27 Feb 2013 14:27:03 -0800 (PST) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id CA1DA21F84FF for ; Wed, 27 Feb 2013 14:27:02 -0800 (PST) Envelope-to: sidr@ietf.org Received: from rrcs-67-52-140-5.west.biz.rr.com ([67.52.140.5] helo=mw-PC.safetynetaccess.com) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UApSm-000Fh2-QE; Wed, 27 Feb 2013 23:27:01 +0100 Date: Wed, 27 Feb 2013 14:26:55 -0800 (Pacific Normalzeit (Mexiko)) From: Matthias Waehlisch To: Andree Toonk In-Reply-To: <512E8657.7000904@toonk.nl> Message-ID: References: <512E6CDA.1040908@bbn.com> <512E8657.7000904@toonk.nl> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: sidr@ietf.org Subject: Re: [sidr] RPKI Validator for Firefox 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, 27 Feb 2013 22:27:03 -0000 Hi Andree, On Wed, 27 Feb 2013, Andree Toonk wrote: > > Also, since Firefox doesn't know the origin AS for the web page it > > just retrieved, are you using the Team Cymru service to map IP to > > AS? (http://www.team-cymru.org/Services/ip-to-asn.html) > > If the plugin using whois to do this, then you can also do it in one query: > > Easy to parse: > > whois -h whois.bgpmon.net " -m 200.3.12.0/22" > true, but we also looked for a funny application for our RTRlib, which is doing prefix validation in the background. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From waehlisch@ieee.org Wed Feb 27 14:29:23 2013 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 4B1C621F869F for ; Wed, 27 Feb 2013 14:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 EDOgQCWKBzAG for ; Wed, 27 Feb 2013 14:29:22 -0800 (PST) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id C01C721F846E for ; Wed, 27 Feb 2013 14:29:22 -0800 (PST) Envelope-to: sidr@ietf.org Received: from rrcs-67-52-140-5.west.biz.rr.com ([67.52.140.5] helo=mw-PC.safetynetaccess.com) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UApV3-000Frh-Kj; Wed, 27 Feb 2013 23:29:22 +0100 Date: Wed, 27 Feb 2013 14:29:16 -0800 (Pacific Normalzeit (Mexiko)) From: Matthias Waehlisch To: Andrew Chi In-Reply-To: <512E6CDA.1040908@bbn.com> Message-ID: References: <512E6CDA.1040908@bbn.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: sidr wg Subject: Re: [sidr] RPKI Validator for Firefox 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, 27 Feb 2013 22:29:23 -0000 Hi Andrew, On Wed, 27 Feb 2013, Andrew Chi wrote: > > future work ;) ... actually, I would more see the question: "how to > > specify my cache server". Is this of interest? > > Definitely. > > Also, since Firefox doesn't know the origin AS for the web page it just > retrieved, are you using the Team Cymru service to map IP to AS? > (http://www.team-cymru.org/Services/ip-to-asn.html) > yes, for the IP to prefix mapping we are using the Team Cymru service. Hope to come up with a more configurable version before IETF. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From wesley.george@twcable.com Wed Feb 27 14:39:33 2013 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 93BBD21F8519 for ; Wed, 27 Feb 2013 14:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[AWL=0.430, 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 SGd5BUH7LOt9 for ; Wed, 27 Feb 2013 14:39:32 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8151821F8533 for ; Wed, 27 Feb 2013 14:39:32 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,751,1355115600"; d="scan'208";a="34559313" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 27 Feb 2013 17:38:30 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 27 Feb 2013 17:39:23 -0500 From: "George, Wes" To: "sidr@ietf.org" Date: Wed, 27 Feb 2013 17:39:22 -0500 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-01.txt Thread-Index: Ac4R3E63JnNPQsInRGG3H87Y6ghWOgDU8ehg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923041F0C2E2D@PRVPEXVS15.corp.twcable.com> References: <20130223154110.5586.21859.idtracker@ietfa.amsl.com> In-Reply-To: <20130223154110.5586.21859.idtracker@ietfa.amsl.com> 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 Cc: "draft-ietf-sidr-rtr-keying@tools.ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-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: Wed, 27 Feb 2013 22:39:33 -0000 I gave this a review since I am one of the folks who raised my hand as will= ing to be the resident PKI n00b to make sure that things like this are clea= r to "router guys" who are dealing with PKI for the first time outside of m= aybe generating the SSH keys for tty access to a router. The second paragraph of the intro, starting with the sentence "The router-d= riven model is most..." is difficult to parse (grammatically). I recommend = re-wording to eliminate "often times for human subscribers" from the middle= of the phrase and generally streamline the point being made here. Editorial nit: multiple instances of %s/drive/driven 3. instead of serial/craft, I'd just say console. Or more generally, you could refer to in-band management vs out of band, as= that covers a wider set of scenarios than specifically referring to an Eth= ernet port and a serial port. Yes, that doesn't exactly cover the hair-spli= t when people use a management Ethernet port connected to a separate manage= ment network for "in band" (non-console) management of the device, but mayb= e that's clear enough, I don't know. I also don't think proprietary is the right word. Console access via a term= inal server is pretty universal, and unless there's some sort of a tool pus= hing out the initial config snippets over console to bootstrap the box so t= hat it can talk to it inband and finish the provisioning, "operator going t= ypey-typey on a terminal" is definitely not proprietary either. Another thought - console access via remote terminal server isn't actually = secure in every case. In a typical setup you have: User host -> (ssh) bastion/jump box -> (telnet) local terminal server -> RS= 232/USB connection to console Unless the path between the jump box and the local terminal server is such = that it is nearly impossible to sniff the traffic (private network, direct = connection, etc) using this to provision sensitive config might be ill-advi= sed. Might be worth explicitly stating that for this reason, use of the con= sole to provision the SIDR keys is NOT recommended. It's not clear to me whether the method being described in this first part = of section 3 is actually important. Do you actually have to do something di= fferent in the way that you bring a router online (get it basic connectivit= y to the network) in this process in order to preserve proper security and = trust for the keys, or is this just illustrating a typical process to provi= sion a router from bare metal such that you have secure access to it to fur= ther manipulate the configuration? Is certificate-based authentication (ins= tead of password auth) a MUST, or a SHOULD, or does it matter? If this is j= ust illustrating a standard example, you can probably just say something li= ke "this assumes that standard (BCP?) procedures have been followed to init= ially configure the router for secure remote access, via either inband or o= ut of band means" and then just specify that it's necessary to have the sec= ure connection between the router and operator before the router keying for= SIDR is done (because....). Some of this is down in the security considera= tions today, and I think it's important to actually discuss it here instead= since it's basically a critical part of the provisioning process. The key = (pun very much intended) thing here is to highlight things that are differe= nt from normal provisioning and explain why they're important. 3.1 - wouldn't it be sFTP/SCP or HTTPS or some similar? Direct/indirect makes sense, but the process for indirect transfer is a lit= tle light on details - what steps must be taken to ensure that the keys are= not compromised in this transfer, either from the router or to the RPKI CA= ? Even a reference to section 5 might be enough to cover this. Also, I don't follow your last sentence "...linkage between private key and= a router..." - why is that important? 3.2 "installed over the ssh session..." - are we talking simple copy and pa= ste of a huge string of text representing the key, or is it actually SCP/SF= TP of a file that is then read into the router's config via additional comm= ands? If you're talking copy/paste, it's probably worth warning that for keys ove= r a certain size, this method is error-prone. I've seen a lot of mangled co= nfig because someone exceeded a paste buffer when trying to copy/paste a co= nfig, especially over a 9600 bps console at the other end of 90ms of latenc= y. 5. when you talk about offload methods, you should probably specify the req= uired/recommended security precautions associated with handling the key so = that it isn't intercepted across the transfer method used (e.g. use SNMPv3 = with encryption, use sFTP/SCP, CLI with SSH, etc, as well as any considerat= ions around chain of possession and level of trust as the keys are stored a= nd transferred between old and new box. There are a lot of risk factors if = a tech is transferring it to his (possibly compromised) laptop when compare= d with transferring to parts of the infrastructure (a config repository ser= ver, for example) that are properly hardened. Also need to discuss sneakernet transfer, where I dump the key to a local s= torage device so that the tech can plug it into the new RP/RE and upload it= that way. This is sometimes important if the box is having issues and as a= result has limited connectivity to offload the keys. Any considerations to= ensure proper security in a transfer like that? Thanks, Wes George > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Saturday, February 23, 2013 10:41 AM > To: i-d-announce@ietf.org > Cc: sidr@ietf.org > Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Inter-Domain Routing Working > Group of the IETF. > > Title : Router Keying for BGPsec > Author(s) : Sean Turner > Keyur Patel > Randy Bush > Filename : draft-ietf-sidr-rtr-keying-01.txt > Pages : 9 > Date : 2013-02-23 > > Abstract: > BGPsec-speaking routers must be provisioned with private keys and the > corresponding public key must be published in the global RPKI > (Resource Public Key Infrastructure). This document describes two > ways of provisioning public/private keys, router-driven and operator- > driven. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 waehlisch@ieee.org Wed Feb 27 14:39:38 2013 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 7133E21F881A for ; Wed, 27 Feb 2013 14:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 0lmBQgdt5GjZ for ; Wed, 27 Feb 2013 14:39:37 -0800 (PST) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id 303A421F8802 for ; Wed, 27 Feb 2013 14:39:37 -0800 (PST) Envelope-to: sidr@ietf.org Received: from rrcs-67-52-140-5.west.biz.rr.com ([67.52.140.5] helo=mw-PC.safetynetaccess.com) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UApex-000H0G-MP; Wed, 27 Feb 2013 23:39:36 +0100 Date: Wed, 27 Feb 2013 14:39:30 -0800 (Pacific Normalzeit (Mexiko)) From: Matthias Waehlisch To: carlos@lacnic.net In-Reply-To: <512E60D9.2010308@gmail.com> Message-ID: References: <512D646C.9020800@lacnic.net> <512E60D9.2010308@gmail.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: sidr@ietf.org Subject: Re: [sidr] RPKI Validator for Firefox 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, 27 Feb 2013 22:39:38 -0000 Hi Carlos, this should be fixed now. There was a problem with the RTR cache and validating LACNIC data. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Wed, 27 Feb 2013, Carlos M. Martinez wrote: > Yup, LACNIC's website resides on a 'valid' prefix. I'm trying other > prefixes from our network and they all appear as 'not-found'. > > Matthias, I'd love to help you troubleshoot the issue. You can contact > me on private if you prefer. > > regards > > ~Carlos > > On 2/26/13 11:42 PM, Arturo Servin wrote: > > > > Very nice! > > > > But it is not working properly, :( > > > > It says that my prefix is unknown when it is valid according to my > > validation: > > > > http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.3.12.0/22/ > > > > (www.lacnic.net) > > > > Does Team Cymru Service has all the TALs updated? > > > > Regards > > as > > > > On 27/02/2013 09:14, Matthias Waehlisch wrote: > >> Hi all, > >> > >> just for fun and inspired by Mozilla RPKI trials, we implemented a > >> Firefox Add-on that provides validation result of the web server's > >> prefix. > >> > >> * https://addons.mozilla.org/addon/rpki-validator/ > >> > >> IP address to prefix mapping is performed by Team Cymru Service, > >> prefix validation is based on the RTRlib. If you like it, let me know > >> ;). > >> > >> > >> See you in Orlando > >> matthias > >> > > _______________________________________________ > > 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 aservin@lacnic.net Wed Feb 27 19:09:01 2013 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 B4E0321F891D for ; Wed, 27 Feb 2013 19:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.907 X-Spam-Level: X-Spam-Status: No, score=0.907 tagged_above=-999 required=5 tests=[AWL=-1.363, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_44=0.6, J_CHICKENPOX_65=0.6, RDNS_NONE=0.1, RELAY_IS_220=2.118] 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 GlZ2qU0Cb88B for ; Wed, 27 Feb 2013 19:09:00 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 97E9721F8916 for ; Wed, 27 Feb 2013 19:08:57 -0800 (PST) Received: from MiniR2D2.local (unknown [220.247.156.145]) by mail.lacnic.net.uy (Postfix) with ESMTP id CA83930843E for ; Thu, 28 Feb 2013 01:08:43 -0200 (UYST) Message-ID: <512ECA3D.5090906@lacnic.net> Date: Thu, 28 Feb 2013 11:08:45 +0800 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: sidr@ietf.org References: <512E6CDA.1040908@bbn.com> <512E8657.7000904@toonk.nl> In-Reply-To: <512E8657.7000904@toonk.nl> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Subject: Re: [sidr] RPKI Validator for Firefox 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, 28 Feb 2013 03:09:01 -0000 Or WEIRDS servers and receive the data in json. At least ours is using the latests WEIRDS drafts for query and response. Regards, as On 28/02/2013 06:19, Andree Toonk wrote: > .-- My secret spy satellite informs me that at 2013-02-27 12:30 PM > Andrew Chi wrote: > >> Also, since Firefox doesn't know the origin AS for the web page it just >> retrieved, are you using the Team Cymru service to map IP to AS? >> (http://www.team-cymru.org/Services/ip-to-asn.html) > > If the plugin using whois to do this, then you can also do it in one query: > > Easy to parse: > > whois -h whois.bgpmon.net " -m 200.3.12.0/22" > BGP Prefix|CC|Origin AS| Origin AS Name| Prefix Description|RPKI > status|First seen|Last seen|#peers > 200.3.12.0/22|UY|28001|LACNIC - Latin American and Caribbean IP > address|LACNIC|ROA validation successful|2011-10-19|2013-02-27|152 > > Or more verbose: > > whois -h whois.bgpmon.net 200.3.12.0/22 > > Prefix: 200.3.12.0/22 > Prefix description: LACNIC > Country code: UY > Origin AS: 28001 > Origin AS Name: LACNIC - Latin American and Caribbean IP address > RPKI status: ROA validation successful > First seen: 2011-10-19 > Last seen: 2013-02-27 > Seen by #peers: 152 > > Cheers, > Andree > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From terry.manderson@icann.org Wed Feb 27 20:49:00 2013 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 A739B21F8B07 for ; Wed, 27 Feb 2013 20:49:00 -0800 (PST) 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 Ll002rcFUfj0 for ; Wed, 27 Feb 2013 20:49:00 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 254BF21F8AFB for ; Wed, 27 Feb 2013 20:49:00 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 27 Feb 2013 20:48:59 -0800 From: Terry Manderson To: Chris Morrow , sidr wg list , "sidr-chairs@tools.ietf.org" , "sidr-ads@tools.ietf.org" Date: Wed, 27 Feb 2013 20:48:56 -0800 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013) Thread-Index: Ac4VbuujO/fGFuVsT2mauJYuA/PM8Q== Message-ID: In-Reply-To: <5126F465.8030005@ops-netman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3444907736_103781363" MIME-Version: 1.0 Subject: Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013) 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, 28 Feb 2013 04:49:00 -0000 --B_3444907736_103781363 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Apologies for taking so long to review this document. This is a well constructed template and I have only 6 concerns to be addressed. 1) My first observation is that the CPS takes an organisational view (and that is expected) of the RPKI CA's in action, and while it certainly provides allowances for multiple CA's within an organisation (s 1.3.1) There are situations that the 'organisation' will have different personalities. To which I would like "organisation" to also explicitly include wording that includes 'business unit.' 2) In section 1.3.5, "Specify the entity that operates=8A" Entity should most definitely be plural. Yes, I accept that is a little(?) picky. 3) Nit: Section 1.6 Page 11. There appears to be an extra "-" in the definition if ISP, NIR, and RPKI-signed object. 4) Section 2.1 "via RSYNC". Can that be adjusted to "standardised mechanisms supported by RPKI"? or something similar? 5) In section 4.1.1, can "Any subscriber who holds..", be amended to "Any vetted and approved subscriber who holds.." 6) Can you explain why compromise and disaster recovery (s5.7) was omitted from the template? Cheers Terry On 22/02/13 2:30 PM, "Chris Morrow" wrote: >WG folks, >As the subject states, let's please start a WGLC poll for the document: > draft-ietf-sidr-cps-01 > > >with the abstract: > "This document contains a template to be used for creating a > Certification Practice Statement (CPS) for an Organization that is > part of the Resource Public Key Infrastructure (RPKI), e.g., a > resource allocation registry or an ISP." > >So far the authors have made a few revisions, with updates based on >comments/feedback, at this time the document has been stable for more >than 6 months time, let's move this along if there are no further >issues/addendums/questions/appendixes. > >thanks! >-chris >co-chair-1-of-3 >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr --B_3444907736_103781363 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ 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+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFKfwcwUMcnNcVrmrz0ayJkOUCXovMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMDIyODA0NDg1NlowDQYJKoZIhvcNAQEBBQAEggEAP3/x0Ja+ HJCXJIUWQPHxa0aD84Vj5NLC7uwQOsM7jFeIrndNBsAPxb67YfFKQV8m4KF5xvzjtW4GwF8N AJtuo91Hhhjl+mSRl1pEILcirlX5SCYwqpHOaIOScikysTTEW8YSLrdxGAuyQUhxMiWdzM6Z XM9M4TdgvH4nngcxWRcl9rMeI1uGQsOJLI6Sf/HV64MIVg8RKJzVS5ygkWXQx66tI64h4K1k qOacrYsy3z1NX9Q9kGEgl90/lNPwRGgkqP0gyPYg997kzCs8WFOVsFkMpDmkMjgOyv1Zm9Rs vJi6SNKNXb3P3Psmy6kW2BPxUu6Q9D3AaYZkUGHEnG7sxA== --B_3444907736_103781363-- From kent@bbn.com Wed Feb 27 22:27:01 2013 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 1949521F8A7B; Wed, 27 Feb 2013 22:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.285 X-Spam-Level: X-Spam-Status: No, score=-106.285 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 SDmy9uuQtkCX; Wed, 27 Feb 2013 22:26:58 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCD721F84A8; Wed, 27 Feb 2013 22:26:27 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:47787 helo=63.147.dhcp.conference.apricot.net) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UAwwg-0001gQ-9S; Thu, 28 Feb 2013 01:26:24 -0500 Message-ID: <512EF88C.1000600@bbn.com> Date: Thu, 28 Feb 2013 01:26:20 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: sidr@ietf.org, Terry Manderson , "sidr-chairs@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020205020207060803080101" Subject: Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013) 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, 28 Feb 2013 06:27:01 -0000 This is a multi-part message in MIME format. --------------020205020207060803080101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Terry, Thanks for the feedback. Below are responses to your comments. On 2/27/13 11:48 PM, Terry Manderson wrote: > Apologies for taking so long to review this document. > > This is a well constructed template and I have only 6 concerns to be > addressed. > > 1) My first observation is that the CPS takes an organisational view (and > that is expected) of the RPKI CA's in action, and while it certainly > provides allowances for multiple CA's within an organisation (s 1.3.1) > There are situations that the 'organisation' will have different > personalities. To which I would like "organisation" to also explicitly > include wording that includes 'business unit.' How about the following revision to the preface: This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Organization that is part of the Resource Public Key Infrastructure (RPKI). (_Throughout this document __ __the term "Organization" is used broadly, e.g., the entity in question might __ __ be a business unit of a larger organization.)_ > 2) In section 1.3.5, "Specify the entity that operatesS(" Entity should > most definitely be plural. Yes, I accept that is a little(?) picky. > 3) Nit: Section 1.6 Page 11. There appears to be an extra "-" in the > definition if ISP, NIR, and RPKI-signed object. fixed. > 4) Section 2.1 "via RSYNC". Can that be adjusted to "standardised > mechanisms supported by RPKI"? or something similar? The RPKI CA will publish certificates, CRLs, and RPKI-signed objects via a repository that is accessible via at . This repository will conform to the structuredescribed in [RFC6481]. > 5) In section 4.1.1, can "Any subscriber who holds..", be amended to "Any > vetted and approved subscriber who holds.." Any subscriber _in good standing_ who holds INRs distributed by this Organization may submit a certificate application to this CA. > 6) Can you explain why compromise and disaster recovery (s5.7) was omitted > from the template? > 5.7. Compromise and disaster recovery Steve --------------020205020207060803080101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Terry,

Thanks for the feedback. Below are responses to your comments.

On 2/27/13 11:48 PM, Terry Manderson wrote:
Apologies for taking so long to review this document.

This is a well constructed template and I have only 6 concerns to be
addressed.

1) My first observation is that the CPS takes an organisational view (and
that is expected) of the RPKI CA's in action, and while it certainly
provides allowances for multiple CA's within an organisation (s 1.3.1)
There are situations that the 'organisation' will have different
personalities. To which I would like "organisation" to also explicitly
include wording that includes 'business unit.'
How about the following revision to the preface:

   This document contains a template to be used for creating a

   Certification Practice Statement (CPS) for an Organization that is

   part of the Resource Public Key Infrastructure (RPKI). (Throughout this document
   the term “Organization” is used broadly, e.g., the entity in question might
  be a business unit of a larger organization.) 
2) In section 1.3.5, "Specify the entity that operatesŠ" Entity should
most definitely be plural. Yes, I accept that is a little(?) picky.

   <Specify one or more entities that operate a repository holding certificates,

   CRLs, and other RPKI-signed objects issued by this Organization, and

   provide a URL for the repository.>

3) Nit: Section 1.6 Page 11. There appears to be an extra "<tab>-" in the
definition if ISP, NIR, and RPKI-signed object.
fixed.
4) Section 2.1 "via RSYNC". Can that be adjusted to "standardised
mechanisms supported by RPKI"? or something similar?

   The <Name of Organization> RPKI CA will publish certificates, CRLs,

   and RPKI-signed objects via a repository that is accessible via

   <insert SIDR-designted protocol name here> at <insert URL here>. This repository will
   conform to the structure described in [RFC6481]. 

5) In section 4.1.1, can "Any subscriber who holds..", be amended to "Any
vetted and approved subscriber who holds.."

   Any subscriber in good standing who holds INRs distributed by this
   Organization may submit a certificate application to this CA.

   

6) Can you explain why compromise and disaster recovery (s5.7) was omitted
from the template?

5.7. Compromise and disaster recovery

 

<Describe your plans for dealing with CA key compromise and how you

plan to continue/restore operation of your RPKI CA in the event of a disaster.>

 


Steve



--------------020205020207060803080101-- From terry@terrym.net Wed Feb 27 22:37:35 2013 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 CBB9E21F8B64 for ; Wed, 27 Feb 2013 22:37:35 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1h042n1ucETi for ; Wed, 27 Feb 2013 22:37:35 -0800 (PST) Received: from mail-da0-f41.google.com (mail-da0-f41.google.com [209.85.210.41]) by ietfa.amsl.com (Postfix) with ESMTP id 28F2021F8B15 for ; Wed, 27 Feb 2013 22:37:35 -0800 (PST) Received: by mail-da0-f41.google.com with SMTP id j17so710891dan.28 for ; Wed, 27 Feb 2013 22:37:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=d7aSPlhjyoOvYumVessoCJm78giW16BpVHNDvx8wj10=; b=gvcj1nQIhtXpYEYsBGAKGcLGc+qb0sCnrvnMMAu/ETSoyH4wQuVtYh3MxaRWDlRjUD H7cKlcGemNVZOUBPJajYdzlb01H0y2AxXxlFCE41F90BQ7Q5UC4XJRCtnz/XWAdfQfCU SskGcYV2Fl14zxG1dnff4HyaI+TyNURPwyHFRGFNNE7bFb7weitK9vcNkCFukEqs9VP6 2mhVJYHlhV9+Lk8jcC3a2fjmVUwgWOqm+q7YIPbbfD4gUSn1xibjG1jO9IE00Q8hCzp3 t4cAoBzXc25bglt8mBrJj/xePzA6jGLaELhYJXiX/GDsAJTHfsjHE2dMrPxbP4zCVQCn CDnw== X-Received: by 10.66.160.230 with SMTP id xn6mr11750822pab.119.1362033454883; Wed, 27 Feb 2013 22:37:34 -0800 (PST) Received: from [192.168.1.103] (c58-107-20-139.fitzg4.qld.optusnet.com.au. [58.107.20.139]) by mx.google.com with ESMTPS id zv5sm6390207pab.2.2013.02.27.22.37.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 22:37:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Terry Manderson In-Reply-To: <512EF88C.1000600@bbn.com> Date: Thu, 28 Feb 2013 16:37:29 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <512EF88C.1000600@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQk6hSRQHL58zjzWxHhMVlP6AjyaCbHtZLLc1JNU+eOcFhFddThmn0SK+P+BJQK+vXpFN2Lf Cc: "sidr-chairs@ietf.org" , sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013) 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, 28 Feb 2013 06:37:35 -0000 Hi Steve, I appreciate the very rapid revisions. I am perfectly happy with all of the proposed revisions below. I think the amended document is ready to progress. Cheers Terry On 28/02/2013, at 4:26 PM, Stephen Kent wrote: > Terry, >=20 > Thanks for the feedback. Below are responses to your comments. >=20 > On 2/27/13 11:48 PM, Terry Manderson wrote: >> Apologies for taking so long to review this document. >>=20 >> This is a well constructed template and I have only 6 concerns to be >> addressed. >>=20 >> 1) My first observation is that the CPS takes an organisational view = (and >> that is expected) of the RPKI CA's in action, and while it certainly >> provides allowances for multiple CA's within an organisation (s = 1.3.1) >> There are situations that the 'organisation' will have different >> personalities. To which I would like "organisation" to also = explicitly >> include wording that includes 'business unit.' >>=20 > How about the following revision to the preface: >=20 > This document contains a template to be used for creating a > Certification Practice Statement (CPS) for an Organization that is > part of the Resource Public Key Infrastructure (RPKI). (Throughout = this document=20 > the term =93Organization=94 is used broadly, e.g., the entity in = question might=20 > be a business unit of a larger organization.)=20 >> 2) In section 1.3.5, "Specify the entity that operates=8A" Entity = should >> most definitely be plural. Yes, I accept that is a little(?) picky. >>=20 > CRLs, and other RPKI-signed objects issued by this Organization, = and > provide a URL for the repository.> >> 3) Nit: Section 1.6 Page 11. There appears to be an extra "-" in = the >> definition if ISP, NIR, and RPKI-signed object. >>=20 > fixed. >> 4) Section 2.1 "via RSYNC". Can that be adjusted to "standardised >> mechanisms supported by RPKI"? or something similar? >>=20 > The RPKI CA will publish certificates, CRLs, > and RPKI-signed objects via a repository that is accessible via > at . = This repository will=20 > conform to the structure described in [RFC6481]. >> 5) In section 4.1.1, can "Any subscriber who holds..", be amended to = "Any >> vetted and approved subscriber who holds.." >>=20 > Any subscriber in good standing who holds INRs distributed by this=20= > Organization may submit a certificate application to this CA. > =20 >> 6) Can you explain why compromise and disaster recovery (s5.7) was = omitted >> from the template? >>=20 >>=20 > 5.7. Compromise and disaster recovery > =20 > plan to continue/restore operation of your RPKI CA in the event of a = disaster.> > =20 >=20 > Steve=20 >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From turners@ieca.com Thu Feb 28 06:30:16 2013 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 B65CC21F857A for ; Thu, 28 Feb 2013 06:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.236 X-Spam-Level: X-Spam-Status: No, score=-102.236 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 mVQBxwLh8yl4 for ; Thu, 28 Feb 2013 06:30:16 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.238.10]) by ietfa.amsl.com (Postfix) with ESMTP id 26AA421F84C9 for ; Thu, 28 Feb 2013 06:30:16 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 492D962921E75; Thu, 28 Feb 2013 08:29:51 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 2CD8C62920A32 for ; Thu, 28 Feb 2013 08:29:48 -0600 (CST) Received: from [108.45.16.214] (port=49732 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UB4Ut-0004bS-3K for sidr@ietf.org; Thu, 28 Feb 2013 08:30:11 -0600 Message-ID: <512F69F1.4090301@ieca.com> Date: Thu, 28 Feb 2013 09:30:09 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: sidr wg list References: <5126F465.8030005@ops-netman.net> In-Reply-To: <5126F465.8030005@ops-netman.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:49732 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013) 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, 28 Feb 2013 14:30:16 -0000 Below are some comments on the draft. I also submitted my nits to the editors. 0) Based on the assumption that draft-newton-sidr-policy-qualifiers will be adopted because that's what the RIRs want should s1.2 or 1.5 also include some information about where it can be found? This information would be identical to the URI included in the policy qualifier? 1) s1.6: CP - Is it worth nothing that there might be another CP for the BPKI? 2) s4.6.1: Not sure if this needs to go here but don't we need to say something about not renewing certificates forever? 3) draft-ietf-sidr-rtr-keying describes the procedures for operator generated keys (i.e., those that are not router generated). A couple of questions come to mind: a) Should the CPS point to that draft in s6.1.2 or will the CPS be updated when draft-ietf-sidr-rtr-keying is published? b) draft-ietf-sidr-rtr-keying allows operators sign the private keys they generate and subsequently send back to the router. Should this be explicitly called out in s4.5.1. For s.4.5.2, is the returned signed-key an RPKI-Signed Object? spt On 2/21/13 11:30 PM, Chris Morrow wrote: > WG folks, > As the subject states, let's please start a WGLC poll for the document: > draft-ietf-sidr-cps-01 > > > with the abstract: > "This document contains a template to be used for creating a > Certification Practice Statement (CPS) for an Organization that is > part of the Resource Public Key Infrastructure (RPKI), e.g., a > resource allocation registry or an ISP." > > So far the authors have made a few revisions, with updates based on > comments/feedback, at this time the document has been stable for more > than 6 months time, let's move this along if there are no further > issues/addendums/questions/appendixes. > > thanks! > -chris > co-chair-1-of-3 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >