From gih@apnic.net Sat Sep 5 19:32:32 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ACFF3A672F for ; Sat, 5 Sep 2009 19:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Apay8z5xHDRJ for ; Sat, 5 Sep 2009 19:32:31 -0700 (PDT) Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id 342863A67B1 for ; Sat, 5 Sep 2009 19:32:31 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10] (unknown [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 5AE06110069 for ; Sun, 6 Sep 2009 12:32:53 +1000 (EST) Message-Id: From: Geoff Huston To: sidr@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 6 Sep 2009 12:32:52 +1000 X-Mailer: Apple Mail (2.936) Subject: [sidr] WG Chair Affiliation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 02:32:32 -0000 WG Co-chair Hat ON There has been some discussion in the wg chairs list about disclosure of affiliation of the WG chairs to the WG. For the record, I would like to note here that I am employed by APNIC, the regional internet registry for the Asia Pacific region. APNIC is not in receipt of any funding or grant that is associated with the activities being undertaken by this working group, as far as I am aware. Geoff Huston From randy@psg.com Mon Sep 7 09:12:28 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC90428C197 for ; Mon, 7 Sep 2009 09:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqWGGUgMAss0 for ; Mon, 7 Sep 2009 09:12:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id CC33D28C194 for ; Mon, 7 Sep 2009 09:12:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mkgpo-00025K-3h; Mon, 07 Sep 2009 16:12:52 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id DD28F29CB2CE; Mon, 7 Sep 2009 09:12:51 -0700 (PDT) Date: Mon, 07 Sep 2009 09:12:51 -0700 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] WG Chair Affiliation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 16:12:29 -0000 geoff, since you bring up the subject, which is conflict of interest, not specifically chair affiliation, excuse me for being my normal tactful self :). in the ivtf, many folk do work that concerns their employer, someone has to pay the costs [0]. it is not whether the emoloyer gets their income by renting integers (and hopes to get it from renting certificates[1]), or by selling hardware or software, or by contracting to concerned users, or by selling gifs of naked furries. the issue is document authors letting their own and their perception of their employer's interests override the expressed concerns and consensus of other wg members and, at the same time, using the wg chair position as a pulpit for those interests. randy --- [0] - http://archive.psg.com/051000.ccr-ivtf.pdf [1] - what i have seen in the sidr wg has driven me into the group which is extremely concerned about the rirs controling routing given their clear lack of altruism for the health of the internet. From terry.manderson@icann.org Thu Sep 10 07:20:44 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D846A3A6954 for ; Thu, 10 Sep 2009 07:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.236 X-Spam-Level: X-Spam-Status: No, score=-5.236 tagged_above=-999 required=5 tests=[AWL=-1.096, BAYES_20=-0.74, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV736h--DN99 for ; Thu, 10 Sep 2009 07:20:43 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id CA85828C1A1 for ; Thu, 10 Sep 2009 07:20:43 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 10 Sep 2009 07:21:17 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Thu, 10 Sep 2009 07:21:15 -0700 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoZgljYyAeQGqcMQ6K478k9oji/twAA1FVRBicSkXQ= Message-ID: In-Reply-To: Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 14:20:44 -0000 On 10/08/09 4:42 PM, "Terry" wrote: >=20 > I don't see this an inventing problems. I think it is realizing that the > mooted interpretation is going to go badly for some in anything but a com= plete > deployment. I would prefer that we, as a working group, aren't putting fo= rward > something that is going to cause pain. I think there are enough hairy mon= sters > surrounding this work already. >=20 > I'm currently putting together an analysis of this from the DFZ as to imp= act. > I'll post again in a few days. >=20 > T. It took me more than a few days to get back to this due to other commitments. I have created a origination map from my view of the BGP table (or DFZ if that term doesn't offend you). You will find a map from a recent bgp dump here: http://stats.research.icann.org/bgp/cidr-map/origin-map.bgp.20090909.1200.h= t ml I have categorized prefixes I see as: Aggregate: the least specific prefixes seen Deaggregated: where the same AS that has the aggregate, originates more specific prefixes Suballocated: where a different AS originates a more specific from a aggregate or deaggregate prefix Sub-Suballocated: where a different AS originates a more specific from = a Suballocted prefix Sub-Sub-Suballocated: where a different AS originates a more specific from a Sub-Suballocated prefix Sub-Sub-Sub-Suballocated: where a different AS originates a more specific from a Sub-Sub-Suballocated prefix the prefix tally is: 147300 Aggregate 92275 Deaggregated 50125 Suballocated 1420 Sub-Suballocated 16 Sub-Sub-Suballocated 1 Sub-Sub-Sub-Suballocated If the WG maintains the idea that a ROA represents an implicit deny as previously discussed - I believe in terms of a deployment of rpki, the current interpretation represents a significant blocker. Presuming what I see in BGP is a mostly accurate representation of intent, all sub*allocated prefixes must have a valid ROA and (and obviously certificate state) before any aggregate or deaggrgate prefix ROAs can be issued. This is backward to the current top-down approach of resource certs of IANA->RIRs->NIR|LIR->ISP->Multihomed-endsite. That is resource certs nee= d to be issued first, top-down, but ROAs (etc) need to created bottom up else breakage will occur from routes being deemed invalid. So a good 20% of the prefix's need to be issued ROA's before any trust statements can be made about most of the aggregate prefixes. To complete the analysis, the deaggregated prefixes could be covered by the same ROA as the aggregate (except with maxLength tweaking) - but again coul= d not be created prior to any suballocated prefix' ROAs being created. The alternate approach would be to create ROAs just for the 92275 deaggregates, provided they didn't have any suballocations (which many do) or the suballocated prefix ROAs already existed. Please SIDR-WG, consider a ROA to not have any deny interpretations or implications to allow a soft deployment, in a sensible top down manner. I'll come back to the WG in a few days, where "few" is in the range 1-100, with some analysis that supports both AS0-ROA and, to larger extent, BOA du= e to observations of unallocated/reserved AS numbers and prefixes. Cheers Terry (the disclaimer applies that this analysis is based on what I see from just one BGP peer) From ggm@apnic.net Thu Sep 10 17:44:45 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E80E3A6407 for ; Thu, 10 Sep 2009 17:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.593 X-Spam-Level: X-Spam-Status: No, score=0.593 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_05=-1.11, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJWmcC+SFH1b for ; Thu, 10 Sep 2009 17:44:44 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 776463A63EC for ; Thu, 10 Sep 2009 17:44:44 -0700 (PDT) Received: from dynamic202.apnic.net (dynamic202.apnic.net [203.119.42.202]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 86D5AD588E; Fri, 11 Sep 2009 10:48:12 +1000 (EST) Message-Id: <3B990533-FC6E-46C1-A4F0-392EE4F1A3AB@apnic.net> From: George Michaelson To: Sandra Murphy , Geoff Huston Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 11 Sep 2009 10:45:17 +1000 X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: [sidr] request to open document issue tracking X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 00:47:34 -0000 Dear Working group chairs. Please can we move to using the ietf tools issue tracker on the working group drafts. I think this would help by clearly identifying issues. -George From terry.manderson@icann.org Thu Sep 10 17:49:36 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673F63A67F4 for ; Thu, 10 Sep 2009 17:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh88B+6UVNib for ; Thu, 10 Sep 2009 17:49:35 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id C66E63A63EC for ; Thu, 10 Sep 2009 17:49:35 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 10 Sep 2009 17:50:11 -0700 From: Terry Manderson To: George Michaelson , Sandra Murphy , Geoff Huston Date: Thu, 10 Sep 2009 17:50:10 -0700 Thread-Topic: [sidr] request to open document issue tracking Thread-Index: AcoyeZdEGCV5mcb/SA2OWaGyn89k7gAADj8a Message-ID: In-Reply-To: <3B990533-FC6E-46C1-A4F0-392EE4F1A3AB@apnic.net> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] request to open document issue tracking X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 00:49:36 -0000 I second that motion! Terry On 11/09/09 10:45 AM, "George Michaelson" wrote: > Dear Working group chairs. >=20 > Please can we move to using the ietf tools issue tracker on the > working group drafts. >=20 > I think this would help by clearly identifying issues. >=20 > -George > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From drc@virtualized.org Fri Sep 11 14:52:57 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C5B3A68FC for ; Fri, 11 Sep 2009 14:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOkLf3gFo2M0 for ; Fri, 11 Sep 2009 14:52:56 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 879B03A68F1 for ; Fri, 11 Sep 2009 14:52:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id D84AC7C5448; Fri, 11 Sep 2009 14:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHlgvddQReik; Fri, 11 Sep 2009 14:53:32 -0700 (PDT) Received: from [192.168.1.3] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 69D877C543D; Fri, 11 Sep 2009 14:53:32 -0700 (PDT) Message-Id: <6D0984A9-12A9-4B16-8EAC-6EA391176510@virtualized.org> From: David Conrad To: Randy Bush In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 11 Sep 2009 14:53:32 -0700 References: X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 21:52:57 -0000 Hi, I choose not to get into discussions of conflict of interest aspect of this thread as I prefer to remain naive and assume folks are doing what they believe is in the best interests of the Internet over the long term. However, I'd like to use a footnote from Randy's note to ask what I'm guessing is a stupid question: On Sep 7, 2009, at 9:12 AM, Randy Bush wrote: > [1] - what i have seen in the sidr wg has driven me into the group > which > is extremely concerned about the rirs controling routing given > their clear lack of altruism for the health of the internet. I, perhaps more than most, have had the recent 'joyful' experience of trying to get a security system that has a hierarchical trust model actually deployed. Suffice it to say, it is a non-trivial exercise in non-technical negotiation. From my perhaps biased perspective it would seem that while conceptually and technically, hierarchical trust models are nice and elegant and simple, they do NOT easily map into political and economic realities which are decidedly non- hierarchical. As a result, deployment has required a tremendous amount of time and thrust to actually make appreciable forward progress. So, here we are, coming up with yet another security system with a hierarchical trust model (whether there is one root or five or six is irrelevant). However, in this case and as I understand it, implementation of this particular security system can (note: not must) imply the root or roots has, as Randy notes, the ability to _control the routing system_, potentially in real time. I will admit some skepticism that this will be remotely acceptable, either in a political or business sense. As such, I have to assume I misunderstand something fundamental about the intent or trust model of SIDR. Could someone enlighten me why enterprises, ISPs, or governments who are NOT the roots of this system won't recoil in horror at even the idea that their parents, grandparents, great-grandparents, etc. in the trust hierarchy potentially could, by intent, whim, or error, instantly and completely remove their ability to send/receive Internet traffic[1]? Thanks, -drc [1] Note that the actual accuracy of this statement is not particularly relevant since there will be folks who will spin the capabilities of the system in this way. From curtis@occnc.com Sun Sep 13 17:14:56 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E91F3A691B for ; Sun, 13 Sep 2009 17:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXF66grdxWR5 for ; Sun, 13 Sep 2009 17:14:55 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 2E8C43A63EB for ; Sun, 13 Sep 2009 17:14:54 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id n8E0Fais044750; Sun, 13 Sep 2009 20:15:36 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> To: David Conrad From: Curtis Villamizar In-reply-to: Your message of "Fri, 11 Sep 2009 14:53:32 PDT." <6D0984A9-12A9-4B16-8EAC-6EA391176510@virtualized.org> Date: Sun, 13 Sep 2009 20:15:36 -0400 Sender: curtis@occnc.com Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 00:14:56 -0000 In message <6D0984A9-12A9-4B16-8EAC-6EA391176510@virtualized.org> David Conrad writes: [ trimmed ] > > Could someone enlighten me why enterprises, ISPs, or governments > who are NOT the roots of this system won't recoil in horror at even > the idea that their parents, grandparents, great-grandparents, etc. in > the trust hierarchy potentially could, by intent, whim, or error, > instantly and completely remove their ability to send/receive Internet > traffic[1]? > > Thanks, > -drc > > [1] Note that the actual accuracy of this statement is not > particularly relevant since there will be folks who will spin the > capabilities of the system in this way. Hi David, Maybe they'd be OK with this because they are already dependent on DNS where their parents, grandparents, great-grandparents, etc. in the [hierarchy] potentially could, [screw up]. DNS has at times been victum of error at or near the top level. Are you expecting a new round of conspiracy theories? Curtis From christopher.morrow@gmail.com Sun Sep 13 19:12:24 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E593A659B for ; Sun, 13 Sep 2009 19:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB4e2HeA0dPR for ; Sun, 13 Sep 2009 19:12:23 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id AEFA43A683F for ; Sun, 13 Sep 2009 19:12:23 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so960552qwi.31 for ; Sun, 13 Sep 2009 19:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=3HfV99CO9RRhTw4eziuXF38JTKnD6iQXb9yfCv6vAic=; b=ewLSciAvmUr4MB7cPbgJWSg+OZI57M/bBMUgUzJ6Jj1aj81kHvm/4XEHY2y5emmgft qNd0P7aesfV983HMyF3oHT6jsMP6eKW0UEex+MI7V4i2xyb7D9+KJNFVIslCtjx4npi+ VBLPPRoXUt1nMyW6U6FyS/SiWFMQzlj+d4wZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=wra0VzkwNMdh3wgcb8Fs7sS/IPINlRcjKX+S6GUsX/3O14n7c3M7LjAQFHEW4vf02r pJdyZNl0g/MYSyQx7jOybnciLl85n8uUejtce/4t3epJJLcPOF39zQMc9ODfDPX++I/v O0PWzfH2FTZ8CN6GSwVVNME+lgLjWPjU+VZ8I= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.93.77 with SMTP id u13mr4694536qam.226.1252894381444; Sun, 13 Sep 2009 19:13:01 -0700 (PDT) In-Reply-To: <6D0984A9-12A9-4B16-8EAC-6EA391176510@virtualized.org> References: <6D0984A9-12A9-4B16-8EAC-6EA391176510@virtualized.org> Date: Sun, 13 Sep 2009 22:13:01 -0400 X-Google-Sender-Auth: 206c0ab1f4ff8ebc Message-ID: <75cb24520909131913w38847f08lf554a511007d3ff5@mail.gmail.com> From: Christopher Morrow To: David Conrad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 02:12:24 -0000 On Fri, Sep 11, 2009 at 5:53 PM, David Conrad wrote: > On Sep 7, 2009, at 9:12 AM, Randy Bush wrote: >> >> [1] - what i have seen in the sidr wg has driven me into the group which >> =A0 =A0 is extremely concerned about the rirs controling routing given >> =A0 =A0 their clear lack of altruism for the health of the internet. > > I, perhaps more than most, have had the recent 'joyful' experience of try= ing > to get a security system that has a hierarchical trust model actually > deployed. =A0Suffice it to say, it is a non-trivial exercise in non-techn= ical > negotiation. =A0From my perhaps biased perspective it would seem that whi= le > conceptually and technically, hierarchical trust models are nice and eleg= ant > and simple, they do NOT easily map into political and economic realities > which are decidedly non-hierarchical. =A0As a result, deployment has requ= ired > a tremendous amount of time and thrust to actually make appreciable forwa= rd > progress. Today, in some respects, there is a hierarchy in place for the routing system, the RADb/IRR datasets which are used to generate route filters. Hopefully the 'next best thing' will include some bits to easily verify authorization to announce/use the address blocks in question, something slightly more accurate than: route: 216.239.63.0/24 descr: REACH (Customer Route) tech-c: RRNOC1-REACH origin: AS24077 remarks: This auto-generated route object was created remarks: for a REACH customer route vs: route: 216.239.63.0/24 descr: Google origin: AS15169 notify: noc@google.com mnt-by: MAINT-AS15169 changed: noc@google.com 20090902 source: RADB which one should be used? Today you don't really know so happily AS24077: aut-num: AS24077 as-name: TMHK-Transit-AS-HK-AP descr: TMHK Global Transit country: HK person: Raymond Tong nic-hdl: RT236-AP e-mail: rtong@telekommalaysia.com.hk Can happily announce a bunch of things that aren't theirs to announce :( oops... In the first stage of 'tomorrow-tomorrow-land' hopefully we'll be able to distinguish who's the right origin-AS. In the next stage we may even be able to tell what AS-PATH's are proper. > I will admit some skepticism that this will be remotely acceptable, eithe= r > in a political or business sense. =A0As such, I have to assume I misunder= stand > something fundamental about the intent or trust model of SIDR. Could some= one > enlighten me why enterprises, ISPs, or governments who are NOT the roots = of > this system won't recoil in horror at even the idea that their parents, > grandparents, great-grandparents, etc. in the trust hierarchy potentially > could, by intent, whim, or error, instantly and completely remove their > ability to send/receive Internet traffic[1]? I'm not sure there's a good answer to this, today we all depend upon some level of trust with the 'IRR system' which we don't have any real contractual relationship with, save individual relationships with 'RADb' the others (alt-db, l3-db, reach-db...) all are blindly trusted. Tomorrow we'd have some relationship (hopefully) with an RIR (which we have today, save legacy folk). Yes, the RIR's of the world will have to step up and provide bullet-proof services, potentially scaled up far more than what's in place today, and potentially geographically dispersed, diverse and redundant... -chris From drc@virtualized.org Mon Sep 14 12:57:39 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5823A6A55 for ; Mon, 14 Sep 2009 12:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGt79OAQm6BM for ; Mon, 14 Sep 2009 12:57:38 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 45CEE3A6AB3 for ; Mon, 14 Sep 2009 12:57:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 93EDB7D08DC; Mon, 14 Sep 2009 12:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2P+JJMPUB+N; Mon, 14 Sep 2009 12:58:22 -0700 (PDT) Received: from [192.168.1.3] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id E1B967D08D1; Mon, 14 Sep 2009 12:58:21 -0700 (PDT) Message-Id: <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> From: David Conrad To: curtis@occnc.com In-Reply-To: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 14 Sep 2009 12:58:20 -0700 References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 19:57:39 -0000 Curtis, On Sep 13, 2009, at 5:15 PM, Curtis Villamizar wrote: > Maybe they'd be OK with this because they are already dependent on DNS > where their parents, grandparents, great-grandparents, etc. in the > [hierarchy] potentially could, [screw up]. The DNS model is somewhat different than what I understand is being proposed here. The folks who manage the top-level (under contract to the US government) can merely make requests to change the top-level, they do not actually control it. There are also explicit statements that the national level resources (that is, ccTLDs) are considered sovereign and the top-level manager can not (under terms of the contract with the USG as well as by practices and polices that require in-country representation) do anything not explicitly requested by the representatives of the nation (more or less -- who the representatives are is a bit grey). The folks who actually control the top-level (an independent party to the manager, again under a USG contract), are explicitly prohibited from making any change that isn't explicitly requested by the manager. And then there are the folks who actually publish the changes who are yet another independent party. In other words, there is no single entity with 'skin in the game' that has control over the top-level. With SIDR, again as I understand it (and I'm looking forward to being corrected), the idea is to have 1 or 5 or 6 trust anchors that are administered by the allocating authorities who both manage the top- level as well as control the top-level. There isn't a clear national- level analog (that is, there aren't national-level blocks), and the only parties being discussed as being involved in administration are non-governmental. Let me simplify this by trying a scenario to see if I understand things. Suppose the UK government decides it is inappropriate (for whatever reason) to pay the RIPE fees associated with maintenance of 51/8 (for sake of argument, assume such fees exist). In the world of SIDR, with certificates which can be used to (at least) derive filters of good vs. bad blocks of addresses, RIPE can now cause 51/8 to be filtered out from any ISP's routing configuration (assuming they auto- generate filters from SIDR-based information). Is this scenario accurate? > Are you expecting a new round of conspiracy theories? Expecting: most definitely. But more to the point, experiencing already: yes. Regards, -drc From schnizlein@isoc.org Mon Sep 14 13:04:44 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1389A3A68AF for ; Mon, 14 Sep 2009 13:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=1.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC99nny4PYn3 for ; Mon, 14 Sep 2009 13:04:43 -0700 (PDT) Received: from smtp121.iad.emailsrvr.com (smtp121.iad.emailsrvr.com [207.97.245.121]) by core3.amsl.com (Postfix) with ESMTP id 562EA3A67B3 for ; Mon, 14 Sep 2009 13:04:43 -0700 (PDT) Received: from relay2.r2.iad.emailsrvr.com (localhost [127.0.0.1]) by relay2.r2.iad.emailsrvr.com (SMTP Server) with ESMTP id 2801444C357; Mon, 14 Sep 2009 16:05:28 -0400 (EDT) Received: by relay2.r2.iad.emailsrvr.com (Authenticated sender: schnizlein-AT-isoc.org) with ESMTPSA id 0659044C366; Mon, 14 Sep 2009 16:05:26 -0400 (EDT) Message-Id: <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> From: John Schnizlein To: David Conrad In-Reply-To: <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 14 Sep 2009 16:05:26 -0400 References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 20:04:44 -0000 David, What you may be looking for is Steve Kent's Trust Anchor Management presentation (and the errata slide 13) - the last items in the SIDR materials from IETF 75. https://datatracker.ietf.org/meeting/75/materials.html John On 2009Sep14, at 3:58 PM, David Conrad wrote: > With SIDR, again as I understand it (and I'm looking forward to > being corrected), the idea is to have 1 or 5 or 6 trust anchors that > are administered by the allocating authorities who both manage the > top-level as well as control the top-level. From terry.mndrsn@gmail.com Mon Sep 14 16:51:03 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A7B3A6832 for ; Mon, 14 Sep 2009 16:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX1B73TaESvg for ; Mon, 14 Sep 2009 16:51:02 -0700 (PDT) Received: from mail-qy0-f178.google.com (mail-qy0-f178.google.com [209.85.221.178]) by core3.amsl.com (Postfix) with ESMTP id A1B443A6867 for ; Mon, 14 Sep 2009 16:51:02 -0700 (PDT) Received: by qyk8 with SMTP id 8so2883314qyk.24 for ; Mon, 14 Sep 2009 16:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=vccnePLMyrQ12hW4D0vBYWq7mAQhu4EEeYix85m+taI=; b=BQ0AHww+mg/RizJdzyMzDJIR9jiey5S66GqV/0I/Et6eIeh2Rs9gHSdkBwjrx7WIY/ QQnDLbwEQfhazv4ow83Kh9/H6Z+Q+S4Je7c1VGfkfxYNnwVyeGFSJGtiZ0g67T0Ptxcz bw4LQXMYH3J1tNJVwAJ+iLeArQ+p2rcMbUGk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Nen/KIx7bLezMRvGe3HeYAlqz65yxH8jbplciPrz1gFF2Uy0LJAzI3tZ/QumYJn2GW vll4MhnutBpPgiVmKiSfKV2nniLhDAbtgTSl7CxkalszGIP4JhLfivvoqMm5z1BDXuPG r65Ua7LSw9obK5GFGUW8mjR1CF09rRxfr3kUo= Received: by 10.224.85.80 with SMTP id n16mr5708771qal.200.1252972304164; Mon, 14 Sep 2009 16:51:44 -0700 (PDT) Received: from ?192.168.1.100? ([114.77.128.245]) by mx.google.com with ESMTPS id 5sm1236274qwg.41.2009.09.14.16.51.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Sep 2009 16:51:43 -0700 (PDT) Sender: Terry Manderson Message-Id: <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> From: Terry Manderson To: John Schnizlein In-Reply-To: <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 15 Sep 2009 09:51:36 +1000 References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 23:51:03 -0000 Hi John, While I appreciate the work by Steve here to allow a relying party to put on the rose coloured validation glasses, it is an inside view looking out. That means is allows an organisation to locally say what it believes is the RPKI view of the world irrespective of what is said globally. So it certainly has its place - but doesn't address David's position completely where an organisation, such as the UK government, might wish to validly assert their own independent trust anchor for their 51/8 SIDR hierarchy and have the rest of the relying parties on the internet collect it and validate routes against it. Perhaps some focus needs to be placed on truly dealing with multiple (>6) trust anchors in a sense where some globally recognised trust anchor repository might exist and TAs are vetted for correctness of both the TA's 3779 extensions and the organisation mooting ownership in some open, transparent, and unbiased mode. In this fashion, if an organisation (say UK) did wish to secede from RIPE, they could still be a party to the global (trusted) routing system by having their own valid and recognised TA. Cheers Terry On 15/09/2009, at 6:05 AM, John Schnizlein wrote: > David, > > What you may be looking for is Steve Kent's Trust Anchor Management > presentation (and the errata slide 13) - the last items in the SIDR > materials from IETF 75. > > https://datatracker.ietf.org/meeting/75/materials.html > > John > > On 2009Sep14, at 3:58 PM, David Conrad wrote: > >> With SIDR, again as I understand it (and I'm looking forward to >> being corrected), the idea is to have 1 or 5 or 6 trust anchors >> that are administered by the allocating authorities who both manage >> the top-level as well as control the top-level. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Mon Sep 14 18:03:20 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C6B3A6932 for ; Mon, 14 Sep 2009 18:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KtrF2AbGLtE for ; Mon, 14 Sep 2009 18:03:19 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1144B3A67E9 for ; Mon, 14 Sep 2009 18:03:19 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.243.16.80]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MnMSg-0003fX-BJ; Mon, 14 Sep 2009 21:04:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> Date: Mon, 14 Sep 2009 21:03:41 -0400 To: Terry Manderson From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-959145854==_ma============" Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 01:03:20 -0000 --============_-959145854==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 9:51 AM +1000 9/15/09, Terry Manderson wrote: >Hi John, > >While I appreciate the work by Steve here to allow a relying party >to put on the rose coloured validation glasses, it is an inside view >looking out. That means is allows an organisation to locally say >what it believes is the RPKI view of the world irrespective of what >is said globally. Terry, I think you misunderstand the nature of trust anchors in PKIs. No entity can force all relying parties adopt the entity as a TA, period. The acceptance of a TA is always a local matter, if the software is properly designed. For example, in most of my browsers I can choose to remove the many self-signed CA certs that the browser vendor has chosen to present to me as TAs. Only if the user (RP) is forced to use software that fails to offer such choices does a third party have an ability to impose it's view of who is and is not a TA. This "sphere of influence" notion is applicable in some contexts, but it is not applicable to all the ISPs in the world. So, rather than characterizing the local TA management model that I presented as "rose coloured validation glasses" I would say that it is a realistic representation of what RPs ought to be able to do, and what they will be able to do with the RP software that BBN will make available in open source form. >So it certainly has its place - but doesn't address David's position >completely where an organisation, such as the UK government, might >wish to validly assert their own independent trust anchor for their >51/8 SIDR hierarchy and have the rest of the relying parties on the >internet collect it and validate routes against it. The problem is that nobody, including the UK gov, can ensure that every ISP in the world will recognize it as a TA, period. The sooner folks get past tjis notion the faster we can have meaningful discussions on this topic. Steve --============_-959145854==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] Controlling routing (was Re: WG Chair Affiliati
At 9:51 AM +1000 9/15/09, Terry Manderson wrote:
Hi John,
While I appreciate the work by Steve here to allow a relying party to put on the rose coloured validation glasses, it is an inside view looking out. That means is allows an organisation to locally say what it believes is the RPKI view of the world irrespective of what is said globally.

Terry,

I think you misunderstand the nature of trust anchors in PKIs.  No entity can force all relying parties adopt the entity as a TA, period. The acceptance of a TA is always a local matter, if the software is properly designed. For example, in most of my browsers I can choose to remove the many self-signed CA certs that the browser vendor has chosen to present to me as TAs. Only if the user (RP) is forced to use software that fails to offer such choices does a third party have an ability to impose it's view of who is and is not a TA. This "sphere of influence" notion is applicable in some contexts, but it is not applicable to all the ISPs in the world.

So, rather than characterizing the local TA management model that I presented as "rose coloured validation glasses" I would say that it is a realistic representation of what  RPs ought to be able to do, and what they will be able to do with the RP software that BBN will make available in open source form.


So it certainly has its place - but doesn't address David's position completely where an organisation, such as the UK government, might wish to validly assert their own independent trust anchor for their 51/8 SIDR hierarchy and have the rest of the relying parties on the internet collect it and validate routes against it.

The problem is that nobody, including the UK gov, can ensure that every ISP in the world will recognize it as a TA, period. The sooner folks get past tjis notion the faster we can have meaningful discussions on this topic.

Steve
--============_-959145854==_ma============-- From terry.mndrsn@gmail.com Mon Sep 14 18:42:21 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3BF83A6914 for ; Mon, 14 Sep 2009 18:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GKhdmp+zLZy for ; Mon, 14 Sep 2009 18:42:18 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id B81DE3A6895 for ; Mon, 14 Sep 2009 18:42:15 -0700 (PDT) Received: by ewy3 with SMTP id 3so3301043ewy.42 for ; Mon, 14 Sep 2009 18:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=BsKLzt6W18kFq4YW3ZWop/jmyh8qBj+bFMMwkSX8BlY=; b=SUVjbTSwBebWTEeWnl40PcVq+EARhfLOq4EaTRFToR01VYQLJwnJuETWam5HuB6q7Z cK7p+5vW/hSxfnnxN+gWosL109mkzepuL4BtLWTJ0F3kXHCBGkodZ4NdYoJ183p/WwbG E9l/1+gsXIIq0RsGia6UpPlJ3w4lpUJl0FHc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Vqy5dac1zoSzkqDVThYEEhPXHk+Jeg6HNmUlzn28sr9fkAdgg3bzIasi51T6bcx01W hzfZSTlaIVvw6S/HJz77MxrIv1Rp+fyzFuOG6ag+KDoNR0osaSBsI6h9a/kyzVktCANO +Y+xQbppaP+NV9w6aH9hAWJR1Hb7kgyvLc9Tc= Received: by 10.211.147.5 with SMTP id z5mr7651366ebn.87.1252978975778; Mon, 14 Sep 2009 18:42:55 -0700 (PDT) Received: from ?192.168.1.100? ([114.77.128.245]) by mx.google.com with ESMTPS id 10sm57293eyz.34.2009.09.14.18.42.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Sep 2009 18:42:54 -0700 (PDT) Sender: Terry Manderson Message-Id: <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> From: Terry Manderson To: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 15 Sep 2009 11:42:46 +1000 References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 01:42:21 -0000 Hi Steve, On 15/09/2009, at 11:03 AM, Stephen Kent wrote: > Terry, > > I think you misunderstand the nature of trust anchors in PKIs. No > entity can force all relying parties adopt the entity as a TA, > period. The acceptance of a TA is always a local matter, if the > software is properly designed. For example, in most of my browsers I > can choose to remove the many self-signed CA certs that the browser > vendor has chosen to present to me as TAs. Only if the user (RP) is > forced to use software that fails to offer such choices does a third > party have an ability to impose it's view of who is and is not a TA. > This "sphere of influence" notion is applicable in some contexts, > but it is not applicable to all the ISPs in the world. > I see slight differences in the RPKI, in that we have overlap and uniqueness issues. I agree that no one can force any replying party to use any particular single or set of trust anchors. But lets say two entities near this sphere of influence have the same prefix in their TA which filters down to two contradictory ROAs. How does a relying party make that "TA use" statement? How do they reasonably or programmatically decide? Does your software help them choose which is true? Or is this just a position of the RPKI is TA value agnostic? And if that is so, should the drafts be made to reflect that? Last time I looked there were numerous references to the IANA->RIR->etc hierarchy and technically that is fine - but I think misses David's scenario. > So, rather than characterizing the local TA management model that I > presented as "rose coloured validation glasses" I would say that it > is a realistic representation of what RPs ought to be able to do, > and what they will be able to do with the RP software that BBN will > make available in open source form. > As I said.. I think it is good work. excuse my glib remark, I didn't mean to marginalize it. More as a representation of what a relying party receives and interprets in BGP and in RPKI versus what is announced (by them) and published in RPKI repositories (by them). > >> So it certainly has its place - but doesn't address David's >> position completely where an organisation, such as the UK >> government, might wish to validly assert their own independent >> trust anchor for their 51/8 SIDR hierarchy and have the rest of the >> relying parties on the internet collect it and validate routes >> against it. > > The problem is that nobody, including the UK gov, can ensure that > every ISP in the world will recognize it as a TA, period. Sure. But if we are looking for a qualitative trust statement of TAs, where does one look? Or don't we? Is this just not a problem to care about? > The sooner folks get past tjis notion the faster we can have > meaningful discussions on this topic. > Any discussion that helps clarify a situation or lack of understanding is meaningful. Terry From jmh@joelhalpern.com Mon Sep 14 19:33:51 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80B23A681C for ; Mon, 14 Sep 2009 19:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NT-HeMj24bHF for ; Mon, 14 Sep 2009 19:33:50 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C4E593A67E2 for ; Mon, 14 Sep 2009 19:33:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B3C95430523; Mon, 14 Sep 2009 19:34:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id D4BEA43051A; Mon, 14 Sep 2009 19:34:35 -0700 (PDT) Message-ID: <4AAEFD3A.7010606@joelhalpern.com> Date: Mon, 14 Sep 2009 22:34:34 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stephen Kent References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 02:33:51 -0000 Let me start by saying a couple of positive things: 1) In order to even start on securing this space, we are going to need some sort of certificates 2) As far as I can tell, in order for the certificates to make any sense they have got to be related to the hierarchy of address assignment. (Private addresses are a different matter. SO I do think the approach we are on is the right approach. But, Steve, I think you are misunderstanding the issue David Conrad raises. (What follows is my understanding of what he pointed out, and I could also be confused.) If there is such a hierarchy, tehn, look at what happens from a leaf ISP down the tree. They need to reliably be able to advertise their routes, and have everyone trust their advertiseements if they sign with the key they registered. Given the scope, this almost inherently requires that there be a single (or may a small number of disjoint) starting point. Otherwise, receivers will not have access to and trust of the chains. But now turn it around. Suppose that ISP is unsure as to whether they actually trust the hierarchy. Or even if they trust it now, they are concerned that with a political change, they might not trust the situation then. Yes, you can argue that the ISP can register with whomever they like. But that is only useful if there is trust chain that other people believe between them and that whomever. This turns into a massive political and public relations pain. I don't know a better answer. But ignoring this dimension of the deployment problem will not serve us well. Yours, Joel Stephen Kent wrote: > > At 9:51 AM +1000 9/15/09, Terry Manderson wrote: >> Hi John, >> While I appreciate the work by Steve here to allow a relying party to >> put on the rose coloured validation glasses, it is an inside view >> looking out. That means is allows an organisation to locally say what >> it believes is the RPKI view of the world irrespective of what is said >> globally. > > Terry, > > I think you misunderstand the nature of trust anchors in PKIs. No > entity can force all relying parties adopt the entity as a TA, period. > The acceptance of a TA is always a local matter, if the software is > properly designed. For example, in most of my browsers I can choose to > remove the many self-signed CA certs that the browser vendor has chosen > to present to me as TAs. Only if the user (RP) is forced to use software > that fails to offer such choices does a third party have an ability to > impose it's view of who is and is not a TA. This "sphere of influence" > notion is applicable in some contexts, but it is not applicable to all > the ISPs in the world. > > So, rather than characterizing the local TA management model that I > presented as "rose coloured validation glasses" I would say that it is a > realistic representation of what RPs ought to be able to do, and what > they will be able to do with the RP software that BBN will make > available in open source form. > > >> So it certainly has its place - but doesn't address David's position >> completely where an organisation, such as the UK government, might >> wish to validly assert their own independent trust anchor for their >> 51/8 SIDR hierarchy and have the rest of the relying parties on the >> internet collect it and validate routes against it. > > The problem is that nobody, including the UK gov, can ensure that every > ISP in the world will recognize it as a TA, period. The sooner folks get > past tjis notion the faster we can have meaningful discussions on this > topic. > > Steve > > > ------------------------------------------------------------------------ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From root@core3.amsl.com Mon Sep 14 20:15:01 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C3FF83A67D3; Mon, 14 Sep 2009 20:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090915031501.C3FF83A67D3@core3.amsl.com> Date: Mon, 14 Sep 2009 20:15:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-ta-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 03:15:01 -0000 --NextPart 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 : A Profile for Trust Anchor Material for the Resource Certificate PKI Author(s) : G. Michaelson, et al. Filename : draft-ietf-sidr-ta-01.txt Pages : 18 Date : 2009-09-14 This document defines a standard profile for the publication of Trust Anchor material for the Resource Certificate Public Key Infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ta-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-ta-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-14200315.I-D@ietf.org> --NextPart-- From curtis@occnc.com Mon Sep 14 21:15:43 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFA023A683F for ; Mon, 14 Sep 2009 21:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH1vcdIlbrn5 for ; Mon, 14 Sep 2009 21:15:43 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id D94DC3A6801 for ; Mon, 14 Sep 2009 21:15:42 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id n8F4GRN6068779; Tue, 15 Sep 2009 00:16:27 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <200909150416.n8F4GRN6068779@harbor.orleans.occnc.com> To: David Conrad From: Curtis Villamizar In-reply-to: Your message of "Mon, 14 Sep 2009 12:58:20 PDT." <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> Date: Tue, 15 Sep 2009 00:16:27 -0400 Sender: curtis@occnc.com Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 04:15:43 -0000 In message <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> David Conrad writes: [.. snip, sorry ..] > > Is this scenario accurate? I haven't a clue. :-) I'm out of the layer 8 loop. My understanding is that an entity with a very large address space would be entitled to run their own registry. If it were run the way the IRR was intended to be run, then anyone with a significant amount of address space could appeal to ARIN or ICANN or Jon Postel, or just the other registries to form yet another registry. Since providers have to agree to used it (no small hurdle) if address space isn't at least as cheap as domain names, then it probably won't get any support. Natious would not count for anything but their own infrastructure unless they were providing Internet services and suballocating. Address space should also have consistent rules and consistent pricing from the little guy looking for a /27 for the rack mounts in their basement to the big providers and nations. The most important rule is "no hoarding" - no allocation for addresses that might be used later but that can't be justified today. But this is not a techincal problem and the WG chair would be justified in declaring this discussion out of scope. (Hi Goeff, Sandy - had enough yet?) What ever happended to IPv6? Is routable address space available to meer mortals yet? > > Are you expecting a new round of conspiracy theories? > > Expecting: most definitely. But more to the point, experiencing > already: yes. Sorry to hear that. Not much has changed in that regard. As you know there were almost never conspiracy theories or even so much as ill words spoken regarding the NSFNET program. :-) > Regards, > -drc Best regards, Curtis From curtis@occnc.com Mon Sep 14 21:21:46 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E453A6801 for ; Mon, 14 Sep 2009 21:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmT9gPKwG4D2 for ; Mon, 14 Sep 2009 21:21:45 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 280C43A683F for ; Mon, 14 Sep 2009 21:21:45 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id n8F4MUQC068875; Tue, 15 Sep 2009 00:22:30 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <200909150422.n8F4MUQC068875@harbor.orleans.occnc.com> To: John Schnizlein From: Curtis Villamizar In-reply-to: Your message of "Mon, 14 Sep 2009 16:05:26 EDT." <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> Date: Tue, 15 Sep 2009 00:22:30 -0400 Sender: curtis@occnc.com Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 04:21:46 -0000 In message <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> John Schnizlein writes: > > David, > > What you may be looking for is Steve Kent's Trust Anchor Management > presentation (and the errata slide 13) - the last items in the SIDR > materials from IETF 75. > > https://datatracker.ietf.org/meeting/75/materials.html > > John Its in a vendor proprietary format. Never trust anyone that uses vendor proprietary formats. :-) Curtis From root@core3.amsl.com Mon Sep 14 23:45:01 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 796A93A6849; Mon, 14 Sep 2009 23:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090915064501.796A93A6849@core3.amsl.com> Date: Mon, 14 Sep 2009 23:45:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-ta-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 06:45:01 -0000 --NextPart 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 : A Profile for Trust Anchor Material for the Resource Certificate PKI Author(s) : G. Michaelson, et al. Filename : draft-ietf-sidr-ta-02.txt Pages : 18 Date : 2009-09-14 This document defines a standard profile for the publication of Trust Anchor material for the Resource Certificate Public Key Infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ta-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-ta-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-14233501.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Sep 14 23:45:01 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7E8253A688D; Mon, 14 Sep 2009 23:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090915064501.7E8253A688D@core3.amsl.com> Date: Mon, 14 Sep 2009 23:45:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-res-certs-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 06:45:01 -0000 --NextPart 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 : A Profile for X.509 PKIX Resource Certificates Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-res-certs-17.txt Pages : 34 Date : 2009-09-14 This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-of-use" of an Internet Number Resource (IP Addresses and Autonomous System Numbers). This profile is used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of- use" of the IP addresses and AS numbers that are described in the issued certificate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-res-certs-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-14234147.I-D@ietf.org> --NextPart-- From andrei@ripe.net Tue Sep 15 00:27:37 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF2F3A6994 for ; Tue, 15 Sep 2009 00:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cU8RIE5bvrTX for ; Tue, 15 Sep 2009 00:27:36 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 30FFB3A696D for ; Tue, 15 Sep 2009 00:27:36 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MnSST-0003Vy-64; Tue, 15 Sep 2009 09:28:18 +0200 Received: from andrei-robachevskys-macbook-pro-15.local (andrei.vpn.ripe.net [193.0.21.36]) by herring.ripe.net (Postfix) with ESMTP id 70F0F2F583; Tue, 15 Sep 2009 09:28:12 +0200 (CEST) Message-ID: <4AAF420C.2030209@ripe.net> Date: Tue, 15 Sep 2009 09:28:12 +0200 From: Andrei Robachevsky User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: David Conrad References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> In-Reply-To: <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb21e4c42218bf672c70f13d55648c4841 Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 07:27:37 -0000 David Conrad wrote on 14-09-2009 21:58: [...] > Let me simplify this by trying a scenario to see if I understand things. > Suppose the UK government decides it is inappropriate (for whatever > reason) to pay the RIPE fees associated with maintenance of 51/8 (for > sake of argument, assume such fees exist). In the world of SIDR, with > certificates which can be used to (at least) derive filters of good vs. > bad blocks of addresses, RIPE can now cause 51/8 to be filtered out from > any ISP's routing configuration (assuming they auto-generate filters > from SIDR-based information). > > Is this scenario accurate? > IMO, this is unlikely to happen. However, reclamation of address space is a common practice in the RIR world already today. It happens according to the address allocation policies. The point here is that any changes in holdership of the address space are happening in the registry plane and RPKI is simply a reflection of such changes. May be potentially more efficient than a whois database or an IRR, but pretty much the same. Andrei From kent@bbn.com Tue Sep 15 06:01:42 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4403A6ABC for ; Tue, 15 Sep 2009 06:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaA59t1efGQ4 for ; Tue, 15 Sep 2009 06:01:41 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A86DE3A6A25 for ; Tue, 15 Sep 2009 06:01:41 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.71.0.216]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MnXfv-0002G8-AG; Tue, 15 Sep 2009 09:02:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200909150422.n8F4MUQC068875@harbor.orleans.occnc.com> References: <200909150422.n8F4MUQC068875@harbor.orleans.occnc.com> Date: Tue, 15 Sep 2009 09:02:25 -0400 To: curtis@occnc.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 13:01:42 -0000 At 12:22 AM -0400 9/15/09, Curtis Villamizar wrote: >In message <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> >John Schnizlein writes: >> >> David, >> >> What you may be looking for is Steve Kent's Trust Anchor Management >> presentation (and the errata slide 13) - the last items in the SIDR >> materials from IETF 75. >> >> https://datatracker.ietf.org/meeting/75/materials.html >> >> John > > >Its in a vendor proprietary format. > >Never trust anyone that uses vendor proprietary formats. :-) > >Curtis Oh, I am soooo hurt. Would PDF be OK, despite it's proprietary nature? If you require ASCII art you'll have a very long wait :-). Steve From kent@bbn.com Wed Sep 16 08:24:20 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06AE03A68AA for ; Wed, 16 Sep 2009 08:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53A9sJXVszI6 for ; Wed, 16 Sep 2009 08:24:19 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 01F7A3A679C for ; Wed, 16 Sep 2009 08:24:19 -0700 (PDT) Received: from dhcp89-089-182.bbn.com ([128.89.89.182]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MnvRT-0006ps-Cy; Wed, 16 Sep 2009 10:25:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4AAEFD3A.7010606@joelhalpern.com> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> Date: Wed, 16 Sep 2009 11:25:03 -0400 To: "Joel M. Halpern" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 15:24:20 -0000 Joel, My reply was to specific comments made by Terry, not David's message. David's message was at a higher level. My response (which I did not send) to the question David stated is no, the SDIR model does not assume that IANA or the RIR control routing any more than they do today. They allocate addresses and ASNs, and the RPKI just takes info form the databases maintained by these organizations and represents them in a digitally signed format. This format enables ISPS and other address space holders to generate signed assertions about what ASNs are authorized to originate routes. Thus the issuance of certs by IANA and the RIRs enables ISPs (and others) to improve certain aspects of routing secruity IF they choose to make use of these certs as part of route verification processes. Nonetheless, I will reply to the comments you made. >... >If there is such a hierarchy, tehn, look at what happens from a leaf >ISP down the tree. They need to reliably be able to advertise their >routes, and have everyone trust their advertiseements if they sign >with the key they registered. access and trust are both necessary, but are addressed by somewhat different mechanisms. >Given the scope, this almost inherently requires that there be a >single (or may a small number of disjoint) starting point. >Otherwise, receivers will not have access to and trust of the chains. >But now turn it around. Suppose that ISP is unsure as to whether >they actually trust the hierarchy. Or even if they trust it now, >they are concerned that with a political change, they might not >trust the situation then. Yes, you can argue that the ISP can >register with whomever they like. But that is only useful if there >is trust chain that other people believe between them and that >whomever. I note that there are multiple IRR databases, not just the ones operated by the RIRs. Those databases require ISPs (RPs in the RPKI context) to learn (via out-of-band means) where to find these databases to download the RPSL objects. That is analogous to the RPKI situation. The RPKI design allows very substantial distribution of the RPKI data, and the inclusion of URLs in the certs makes it possible to discover locations "below" publication points that an RP accepts as authoritative. So, the repository side of TA management calls for RPs to select TAs and then follow the pointers from those certs. Pesonally, I hope that the RIRs offer to host data for their members, and sub-allocations, etc. and that most RPs will elect to use those registries, at least as starting points. But, a suspicious RP has other options. Your last sentence (above) is correct (despite ending prematurely :-)) but it is also a fundamental characteristic of any hierarchic system when users of the system want to make provisions to "trust" alternatives to the default hierarchy. I think the RPKI design does a better job of architecting how to do this than most such systems. A few users probably will be sufficiently concerned about misbehavior that they will make alternative publication/certification arrangements. But, I doubt that this will be true of the vast majority of users. >This turns into a massive political and public relations pain. > >I don't know a better answer. >But ignoring this dimension of the deployment problem will not serve us well. This is not being ignored. My presentation on how to perform local TA management was targeting this issue, and I have received very positive feedback from several folks saying that this goes a long way toward addressing their concerns. I think the painful experience that David noted with regard to DNSSEC root issues is influencing the RPKI design. Steve From kent@bbn.com Wed Sep 16 08:52:54 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B7828C1C7 for ; Wed, 16 Sep 2009 08:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V75dN4Oy4b3l for ; Wed, 16 Sep 2009 08:52:53 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 83A6D28C1F6 for ; Wed, 16 Sep 2009 08:52:53 -0700 (PDT) Received: from dhcp89-089-182.bbn.com ([128.89.89.182]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Mnvt4-00073n-EM; Wed, 16 Sep 2009 10:53:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> Date: Wed, 16 Sep 2009 11:53:37 -0400 To: Terry Manderson From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-959006077==_ma============" Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 15:52:54 -0000 --============_-959006077==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Terry, >I see slight differences in the RPKI, in that we have overlap and >uniqueness issues. I agree that no one can force any replying party >to use any particular single or set of trust anchors. But lets say >two entities near this sphere of influence have the same prefix in >their TA which filters down to two contradictory ROAs. How does a >relying party make that "TA use" statement? How do they reasonably >or programmatically decide? Does your software help them choose >which is true? Or is this just a position of the RPKI is TA value >agnostic? And if that is so, should the drafts be made to reflect >that? Last time I looked there were numerous references to the >IANA->RIR->etc hierarchy and technically that is fine - but I think >misses David's scenario. In the local TA management scheme I described, an RP gets to specify the set of resources it believes is associated with a given key (cert). The software enables an RP to assert what it "knows" to be true, overriding what the repositories and the putative TAs may assert. So, if there is a conflict relative to the info that the RP says it knows to be true, what the RP says it knows to be true prevails (locally). If the conflict arises at a point that is below a cert that the RP ad adopted as a TA, and if the RP has no other info about the resources in question, then no, the software can't help with such a problem problem. I think references to the IANA->RIR->... hierarchy are appropriate for describing the extant allocation process. Moreover, it is appropriate to note that the RPKI is designed to mimic that hierarchy. It is also important to note that the choice of TAs is always a local matter. If folks want, I can prepare an (informational) I-D that describes one way of managing TA locally, as per my presentation at the SIDR meeting. >>>So it certainly has its place - but doesn't address David's >>>position completely where an organisation, such as the UK >>>government, might wish to validly assert their own independent >>>trust anchor for their 51/8 SIDR hierarchy and have the rest of >>>the relying parties on the internet collect it and validate routes >>>against it. >> >>The problem is that nobody, including the UK gov, can ensure that >>every ISP in the world will recognize it as a TA, period. > >Sure. But if we are looking for a qualitative trust statement of >TAs, where does one look? Or don't we? Is this just not a problem to >care about? Statements about perceived trust in TAs are useful in PKIs that anoint 3rd parties as TAs, independent of real world authorization. The RPLI is not such a PKI. Instead it seeks to have the real world entities that manage allocation of resources act as CAs. I would urge us to NOT try to make the RPKI into a trusted 3rd party PKI. Steve --============_-959006077==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] Controlling routing (was Re: WG Chair Affiliati
Terry,

I see slight differences in the RPKI, in that we have overlap and uniqueness issues. I agree that no one can force any replying party to use any particular single or set of trust anchors. But lets say two entities near this sphere of influence have the same prefix in their TA which filters down to two contradictory ROAs. How does a relying party make that "TA use" statement? How do they reasonably or programmatically decide? Does your software help them choose which is true? Or is this just a position of the RPKI is TA value agnostic? And if that is so, should the drafts be made to reflect that? Last time I looked there were numerous references to the IANA->RIR->etc hierarchy and technically that is fine - but I think misses David's scenario.

In the local TA management scheme I described, an RP gets to specify the set of resources it believes is associated with a given key (cert). The software enables an RP to assert what it "knows" to be true, overriding what the repositories and the putative TAs may assert. So, if there is a conflict relative to the info that the RP says it knows to be true, what the RP says it knows to be true prevails (locally). If the conflict arises at a point that is below a cert that the RP ad adopted as a TA, and if the RP has no other info about the resources in question, then no, the software can't help with such a problem problem.

I think references to the IANA->RIR->... hierarchy are appropriate for describing the extant allocation process. Moreover, it is appropriate to note that the RPKI is designed to mimic that hierarchy. It is also important to note that the choice of TAs is always a local matter.  If folks want, I can prepare an (informational) I-D that describes one way of managing TA locally, as per my presentation at the SIDR meeting.

So it certainly has its place - but doesn't address David's position completely where an organisation, such as the UK government, might wish to validly assert their own independent trust anchor for their 51/8 SIDR hierarchy and have the rest of the relying parties on the internet collect it and validate routes against it.

The problem is that nobody, including the UK gov, can ensure that every ISP in the world will recognize it as a TA, period.

Sure. But if we are looking for a qualitative trust statement of TAs, where does one look? Or don't we? Is this just not a problem to care about?

Statements about perceived trust in TAs are useful in PKIs that anoint 3rd parties as TAs, independent of real world authorization. The RPLI is not such a PKI. Instead it seeks to have the real world entities that manage allocation of resources act as CAs. I would urge us to NOT try to make the RPKI into a trusted 3rd party PKI.

Steve
--============_-959006077==_ma============-- From Sandra.Murphy@cobham.com Thu Sep 17 05:58:27 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C13B28C215 for ; Thu, 17 Sep 2009 05:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfPigJfuYRYJ for ; Thu, 17 Sep 2009 05:58:26 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2BF8628C134 for ; Thu, 17 Sep 2009 05:58:25 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n8HCx8oK022297; Thu, 17 Sep 2009 07:59:08 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n8HCx8xi028062; Thu, 17 Sep 2009 07:59:08 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.8]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 08:59:07 -0400 Date: Thu, 17 Sep 2009 08:59:06 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Joel M. Halpern" In-Reply-To: <4AAEFD3A.7010606@joelhalpern.com> Message-ID: References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 17 Sep 2009 12:59:08.0003 (UTC) FILETIME=[A49FAB30:01CA3796] Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 12:58:27 -0000 On Mon, 14 Sep 2009, Joel M. Halpern wrote: > Let me start by saying a couple of positive things: > 1) In order to even start on securing this space, we are going to need some > sort of certificates > 2) As far as I can tell, in order for the certificates to make any sense they > have got to be related to the hierarchy of address assignment. (Private > addresses are a different matter. > > SO I do think the approach we are on is the right approach. That's good. > > But, Steve, I think you are misunderstanding the issue David Conrad raises. > (What follows is my understanding of what he pointed out, and I could also be > confused.) > > If there is such a hierarchy, tehn, look at what happens from a leaf ISP down > the tree. They need to reliably be able to advertise their routes, and have > everyone trust their advertiseements if they sign with the key they > registered. I'm not sure what you mean by "the key they registered". When an ISP receives an address allocation, the allocater signs a cert associating that address with a public key, and that public key can come the ISP. Is that what you mean by "the key they registered"? The cert is more a "registration" of the address than it is the registration of the key. > Given the scope, this almost inherently requires that there be a single (or > may a small number of disjoint) starting point. Otherwise, receivers will > not have access to and trust of the chains. > But now turn it around. Suppose that ISP is unsure as to whether they > actually trust the hierarchy. Or even if they trust it now, they are > concerned that with a political change, they might not trust the situation > then. Yes, you can argue that the ISP can register with whomever they like. > But that is only useful if there is trust chain that other people believe > between them and that whomever. What do you mean about not trusting the hierarchy? The RPKI hierarchy represents the hierarchy of address allocation in a cryptographically assured manner. Are you saying that at some point an ISP might not trust the hierarchy by which it receives addresses? I have difficulty conceiving of a (global) mechanism for allocating addresses that would not be hierarchical. So I think that an ISP that was not sure it trusted the address allocation hierarchy would be in a difficult state. I recognize that there is an fear that this system somehow puts ISPs under someone's control. I would answer that there is not any more control than is already the case. We need to emphasize that the cryptography here is just improving the assurance of address relationships that already exist. If there start to be Cert-R-Us signers of RPKI certificates (so "the ISP can register with whomever they like"), that statement will no longer be true, which would be a very bad thing for the trust model. As you note. --Sandy > > This turns into a massive political and public relations pain. Yep. > > I don't know a better answer. > But ignoring this dimension of the deployment problem will not serve us well. I agree whole-heartedly that we need to keep deployment in mind in all our design! Easing into the current operational practice is important, for one thing. --Sandy > > Yours, > Joel > > Stephen Kent wrote: >> >> At 9:51 AM +1000 9/15/09, Terry Manderson wrote: >>> Hi John, >>> While I appreciate the work by Steve here to allow a relying party to put >>> on the rose coloured validation glasses, it is an inside view looking out. >>> That means is allows an organisation to locally say what it believes is >>> the RPKI view of the world irrespective of what is said globally. >> >> Terry, >> >> I think you misunderstand the nature of trust anchors in PKIs. No entity >> can force all relying parties adopt the entity as a TA, period. The >> acceptance of a TA is always a local matter, if the software is properly >> designed. For example, in most of my browsers I can choose to remove the >> many self-signed CA certs that the browser vendor has chosen to present to >> me as TAs. Only if the user (RP) is forced to use software that fails to >> offer such choices does a third party have an ability to impose it's view >> of who is and is not a TA. This "sphere of influence" notion is applicable >> in some contexts, but it is not applicable to all the ISPs in the world. >> >> So, rather than characterizing the local TA management model that I >> presented as "rose coloured validation glasses" I would say that it is a >> realistic representation of what RPs ought to be able to do, and what they >> will be able to do with the RP software that BBN will make available in >> open source form. >> >> >>> So it certainly has its place - but doesn't address David's position >>> completely where an organisation, such as the UK government, might wish to >>> validly assert their own independent trust anchor for their 51/8 SIDR >>> hierarchy and have the rest of the relying parties on the internet collect >>> it and validate routes against it. >> >> The problem is that nobody, including the UK gov, can ensure that every ISP >> in the world will recognize it as a TA, period. The sooner folks get past >> tjis notion the faster we can have meaningful discussions on this topic. >> >> Steve >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 Sandra.Murphy@cobham.com Thu Sep 17 06:53:29 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6968C28C152 for ; Thu, 17 Sep 2009 06:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5QM9aVu6d93 for ; Thu, 17 Sep 2009 06:53:28 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 6DD7E3A677E for ; Thu, 17 Sep 2009 06:53:28 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n8HDsH4k023250; Thu, 17 Sep 2009 08:54:18 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n8HDsF0G030454; Thu, 17 Sep 2009 08:54:17 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.8]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 09:54:14 -0400 Date: Thu, 17 Sep 2009 09:54:12 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Curtis Villamizar In-Reply-To: <200909150416.n8F4GRN6068779@harbor.orleans.occnc.com> Message-ID: References: <200909150416.n8F4GRN6068779@harbor.orleans.occnc.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 17 Sep 2009 13:54:14.0961 (UTC) FILETIME=[57B96A10:01CA379E] Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 13:53:29 -0000 On Tue, 15 Sep 2009, Curtis Villamizar wrote: > > In message <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> > David Conrad writes: > [.. snip, sorry ..] >> >> Is this scenario accurate? > > I haven't a clue. :-) I'm out of the layer 8 loop. > > My understanding is that an entity with a very large address space > would be entitled to run their own registry. If it were run the way > the IRR was intended to be run, then anyone with a significant amount > of address space could appeal to ARIN or ICANN or Jon Postel, or just > the other registries to form yet another registry. Since providers > have to agree to used it (no small hurdle) if address space isn't at > least as cheap as domain names, then it probably won't get any > support. Natious would not count for anything but their own > infrastructure unless they were providing Internet services and > suballocating. Anyone who receives an RPKI certificate to go with their address allocation can run their own CA (the rough analogy to a registry). When they sub-allocate addresses, they *should* issue certificates to go with it. (If they don't want their customer to multi-home, then they don't. Giving a certificate grants the right to use the address, including the right to authorize others to route the address.) If we have a rooted hierarchy, then people just need to know the root(s), and use of the CAs below it comes as part of the package. Prices for address allocations are not affected by the RPKI. > > Address space should also have consistent rules and consistent pricing > from the little guy looking for a /27 for the rack mounts in their > basement to the big providers and nations. The most important rule is > "no hoarding" - no allocation for addresses that might be used later > but that can't be justified today. But this is not a techincal > problem and the WG chair would be justified in declaring this > discussion out of scope. (Hi Goeff, Sandy - had enough yet?) Address allocation policies are a part of the RIR system in response to their membership. The RPKI has no effect on allocation policies - those policies should be discussed in your local RIR. Discussion of address allocation policies are not in scope for sidr (*) (That's a wg chair statement, if you are looking for one.) --Sandy (*) unless a policy in some way impacts the resource certificates. Can't think of a way that could happen, but who knows. > > What ever happended to IPv6? Is routable address space available to > meer mortals yet? > >>> Are you expecting a new round of conspiracy theories? >> >> Expecting: most definitely. But more to the point, experiencing >> already: yes. > > Sorry to hear that. Not much has changed in that regard. > > As you know there were almost never conspiracy theories or even so > much as ill words spoken regarding the NSFNET program. :-) > >> Regards, >> -drc > > Best regards, > > Curtis > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From andrei@ripe.net Thu Sep 17 07:38:39 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5AE43A67F2 for ; Thu, 17 Sep 2009 07:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAEnMcu+MBZk for ; Thu, 17 Sep 2009 07:38:39 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 548AF3A6896 for ; Thu, 17 Sep 2009 07:38:38 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MoI8p-0006qm-AZ; Thu, 17 Sep 2009 16:39:28 +0200 Received: from andrei-robachevskys-macbook-pro-15.local (andrei.vpn.ripe.net [193.0.21.36]) by herring.ripe.net (Postfix) with ESMTP id CA2282F592; Thu, 17 Sep 2009 16:39:22 +0200 (CEST) Message-ID: <4AB24A1A.1030100@ripe.net> Date: Thu, 17 Sep 2009 16:39:22 +0200 From: Andrei Robachevsky User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Stephen Kent References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb9543d714dad37eee577d5bbde1843132 Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 14:38:40 -0000 Stephen Kent wrote on 16-09-2009 17:53: [...] > > Statements about perceived trust in TAs are useful in PKIs that anoint > 3rd parties as TAs, independent of real world authorization. The RPLI is > not such a PKI. Instead it seeks to have the real world entities that > manage allocation of resources act as CAs. I would urge us to NOT try to > make the RPKI into a trusted 3rd party PKI. > I agree. However, I envisage a scenario when the RP in your local TA management scheme announces itself globally as a root CA/TA. And then the question arises how one can distinguish between these ersatz RPKIs and associated stuff (repositories, ROAs, etc.)? > Steve Andrei > > > ------------------------------------------------------------------------ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From drc@virtualized.org Thu Sep 17 09:05:05 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1953A6940 for ; Thu, 17 Sep 2009 09:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.137 X-Spam-Level: X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDrMutcumW7H for ; Thu, 17 Sep 2009 09:05:04 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id C8A9B3A687B for ; Thu, 17 Sep 2009 09:05:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 7C6867DE7B2; Thu, 17 Sep 2009 09:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yms8vijSgC7s; Thu, 17 Sep 2009 09:05:54 -0700 (PDT) Received: from wlan39-146.mdr.icann.org (wlan39-146.mdr.icann.org [192.0.39.146]) by virtualized.org (Postfix) with ESMTP id 184617DE79C; Thu, 17 Sep 2009 09:05:53 -0700 (PDT) Message-Id: <46649EB3-A2C1-438B-91CA-CAF17130C1A8@virtualized.org> From: David Conrad To: Sandra Murphy In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Sep 2009 09:05:52 -0700 References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 16:05:05 -0000 Sandy, On Sep 17, 2009, at 5:59 AM, Sandra Murphy wrote: > I recognize that there is an fear that this system somehow puts ISPs > under someone's control. I would answer that there is not any more > control than is already the case. I suppose it depends on what people are going to do with RPKI. Today, RIR influence on routing is essentially advisory in nature -- if an address holder (say) fails to pay their address maintenance fee, RIRs can, at most, remove the address holder's blocks from whois databases. However, as I understand it, this has limited effect on existing contractual relationships between the address holders and the folks who already announce their space (it may have more effect on address holders who are attempting to find new ISPs to announce their space). The RIR could potentially reallocate the space, but this would likely be a good way of annoying multiple parties (not just the folks the address space was reclaimed from). If RPKI does not change this, then you're right -- there is not any more control. However, if filter lists are built or routers check origin authenticity in real-time by traversing the RPKI tree(s), there would seem to be significantly more control vested in each parent node in the path up to the root of the RPKI hierarchy. My fear is that this will simply be unacceptable in a political or business sense. Regards, -drc From Sandra.Murphy@cobham.com Thu Sep 17 12:24:50 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8A23A68C3 for ; Thu, 17 Sep 2009 12:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIFySzYnW0hy for ; Thu, 17 Sep 2009 12:24:49 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 631C73A67FC for ; Thu, 17 Sep 2009 12:24:49 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n8HJPZTL029925; Thu, 17 Sep 2009 14:25:35 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n8HJPZ9w014637; Thu, 17 Sep 2009 14:25:35 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.8]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 15:25:35 -0400 Date: Thu, 17 Sep 2009 15:25:33 -0400 (Eastern Daylight Time) From: Sandra Murphy To: David Conrad In-Reply-To: <46649EB3-A2C1-438B-91CA-CAF17130C1A8@virtualized.org> Message-ID: References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <46649EB3-A2C1-438B-91CA-CAF17130C1A8@virtualized.org> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 17 Sep 2009 19:25:35.0214 (UTC) FILETIME=[A14748E0:01CA37CC] Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 19:24:50 -0000 On Thu, 17 Sep 2009, David Conrad wrote: > Sandy, > > On Sep 17, 2009, at 5:59 AM, Sandra Murphy wrote: >> I recognize that there is an fear that this system somehow puts ISPs under >> someone's control. I would answer that there is not any more control than >> is already the case. > > I suppose it depends on what people are going to do with RPKI. Today, RIR > influence on routing is essentially advisory in nature -- if an address > holder (say) fails to pay their address maintenance fee, RIRs can, at most, > remove the address holder's blocks from whois databases. However, as I > understand it, this has limited effect on existing contractual relationships > between the address holders and the folks who already announce their space > (it may have more effect on address holders who are attempting to find new > ISPs to announce their space). The RIR could potentially reallocate the > space, but this would likely be a good way of annoying multiple parties (not > just the folks the address space was reclaimed from). Andrei's message acknoledged that address reclamation is a part of RIR daily life. He did not explicitly mention re-allocation to a different party, but I can't imagine holding on to unused address space, particularly in this current era of address-shortage fears. > > If RPKI does not change this, then you're right -- there is not any more > control. However, if filter lists are built or routers check origin > authenticity in real-time by traversing the RPKI tree(s), Those who build filter lists either rely on their customers' reports or on IRR data, which is based on the RIR address allocations. > there would seem to > be significantly more control vested in each parent node in the path up to > the root of the RPKI hierarchy. My fear is that this will simply be > unacceptable in a political or business sense. Political and business fears don't have to be rooted in technical truth, unfortunately. It is up to us to make sure people understand who this relates to current familiar common practice. --Sandy > > Regards, > -drc > From randy@psg.com Thu Sep 17 14:55:19 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9834F3A657C for ; Thu, 17 Sep 2009 14:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-j4zbI-lo7A for ; Thu, 17 Sep 2009 14:55:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id C5BE73A6876 for ; Thu, 17 Sep 2009 14:55:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoOxT-000AMI-76; Thu, 17 Sep 2009 21:56:07 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id D6C202A9CD01; Fri, 18 Sep 2009 06:56:04 +0900 (JST) Date: Fri, 18 Sep 2009 06:56:04 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: <200909150416.n8F4GRN6068779@harbor.orleans.occnc.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 21:55:19 -0000 > Prices for address allocations are not affected by the RPKI. given that at least some RIRs are exploring how and what to charge for certs, this is a bit naive. randy From terry.mndrsn@gmail.com Thu Sep 17 19:31:46 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B543A6930 for ; Thu, 17 Sep 2009 19:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48g66fPBk0HN for ; Thu, 17 Sep 2009 19:31:45 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 828F63A690C for ; Thu, 17 Sep 2009 19:31:45 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 8so247944qwh.31 for ; Thu, 17 Sep 2009 19:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=tCN+BuJg3XeWiRLXNTo2H+yDodiQS+EEqJ1yJH3V0ec=; b=g44V2+KhRKgvPgB2iTEEwgZwP6Yi6+d8XpjgmJa3AxD4FZlM3rcdVIZalPfhAZgQjT S2TfEzD6N9GJ65YHZb6UbqySicg717EwG+5+xKGSx8tpEhDmpQmsYnk4aBE1570FEI3Z fV55j2btWthm7JsAi35QGahi87KO9/1LkiRZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=osq9bH++RfS50q5fJng1FLGjjRrQanwsLXPF96LSvyYpb3s+kGHxaY5K4IXZkque7e mJj5hEDWi5RzvwZeWvb26bMDmpxMmkG/bIOCgbgy0sDTDvyHghg+gWLT96BvweDADjZA SXBSM7Tr0HbI1vTPOyAGvX1kzqMhcuUkDo5rg= Received: by 10.224.30.80 with SMTP id t16mr1004698qac.9.1253241155598; Thu, 17 Sep 2009 19:32:35 -0700 (PDT) Received: from ?192.168.1.103? ([114.77.128.245]) by mx.google.com with ESMTPS id 5sm179922qwh.7.2009.09.17.19.32.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Sep 2009 19:32:34 -0700 (PDT) Sender: Terry Manderson Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Terry Manderson In-Reply-To: Date: Fri, 18 Sep 2009 12:32:27 +1000 Content-Transfer-Encoding: 7bit Message-Id: <82841276-06EC-4A20-A26A-1FA75BCF7E5E@terrym.net> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> To: Stephen Kent X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 02:31:46 -0000 Hi Steve, On 17/09/2009, at 1:53 AM, Stephen Kent wrote: > > In the local TA management scheme I described, an RP gets to specify > the set of resources it believes is associated with a given key > (cert). The software enables an RP to assert what it "knows" to be > true, overriding what the "knows" == "believes" ;-) > repositories and the putative TAs may assert. So, if there is a > conflict relative to the info that the RP says it knows to be true, > what the RP says it knows to be true prevails (locally). If the > conflict arises at a point that is below a cert that the RP ad > adopted as a TA, and if the RP has no other info about the resources > in question, then no, the software can't help with such a problem > problem. right, so the software isn't currently intended to traverse the 'assimilated relying party rpki' to pick out conflicts. nor highlight that in terms of the TA set chosen by the relying party. (I'm saying that is a deficiency, just thinking aloud) > > I think references to the IANA->RIR->... hierarchy are appropriate > for describing the extant allocation process. Moreover, it is > appropriate to note that the RPKI is designed to mimic that > hierarchy. It is also important to note that the choice of TAs is > always a local matter. If folks want, I can prepare an > (informational) I-D that describes one way of managing TA locally, > as per my presentation at the SIDR meeting. I think I would like to see such an I-D. >> >> Sure. But if we are looking for a qualitative trust statement of >> TAs, where does one look? Or don't we? Is this just not a problem >> to care about? > > Statements about perceived trust in TAs are useful in PKIs that > anoint 3rd parties as TAs, independent of real world authorization. > The RPLI is not such a PKI. Instead it seeks to have the real world > entities that manage allocation of resources act as CAs. I would > urge us to NOT try to make the RPKI into a trusted 3rd party PKI. > while I agree the intent isn't to make a 3rd party PKI, won't that happen anyway? At least I see it as likely, irrespective of the allocation resource hierarchy. Cheers Terry From terry.mndrsn@gmail.com Thu Sep 17 21:01:59 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D543A6831 for ; Thu, 17 Sep 2009 21:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guA3aFCUTwi9 for ; Thu, 17 Sep 2009 21:01:58 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 94F6D3A67F8 for ; Thu, 17 Sep 2009 21:01:58 -0700 (PDT) Received: by yxe30 with SMTP id 30so576005yxe.29 for ; Thu, 17 Sep 2009 21:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=vNR0Ise3ifjYHKygv3Os5ps5+m0bL6TMAf3GKegoKoc=; b=mF8GAd7m9WXwixoA7jB+FkpXWKrJR9cAYP+D+PtpredelLe8c2axFUS6Ag4zV1xYau en+VlZ5YRwOrBz0YZKSEAyjPsHJfVLXRtWKOfLObFr4lAiXb3tgHNrToumUjghjLTWzb 0fyvaSXfBE8GTRxQqCM/VUP8lDD687hUqxbGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=nFtxU3aXnhCf1/IVO/kh2kaieEo37eMts7ve82hPCMO2DRoMRhVKs/N9osWEHtvDGn SYwowggTyqFGZBoUw0IQ+NynK+YLxPew7UqtQ/tkbjqGGQbfxpHYHx9zHeLUEA0WNtS3 LOwX/hjIWL3yZun4mqF+q5l9W0xFQmQ3aytY4= Received: by 10.90.216.7 with SMTP id o7mr836493agg.45.1253246568264; Thu, 17 Sep 2009 21:02:48 -0700 (PDT) Received: from ?192.168.1.103? ([114.77.128.245]) by mx.google.com with ESMTPS id 39sm2252846agd.28.2009.09.17.21.02.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Sep 2009 21:02:47 -0700 (PDT) Sender: Terry Manderson Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Terry Manderson In-Reply-To: Date: Fri, 18 Sep 2009 14:02:41 +1000 Content-Transfer-Encoding: 7bit Message-Id: <189DBCB3-A798-4275-956E-92F1519D46E4@terrym.net> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <46649EB3-A2C1-438B-91CA-CAF17130C1A8@virtualized.org> To: Sandra Murphy X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 04:01:59 -0000 Sandy and David, On 18/09/2009, at 5:25 AM, Sandra Murphy wrote: > On Thu, 17 Sep 2009, David Conrad wrote: > >> Sandy, >> >> On Sep 17, 2009, at 5:59 AM, Sandra Murphy wrote: >>> I recognize that there is an fear that this system somehow puts >>> ISPs under someone's control. I would answer that there is not >>> any more control than is already the case. >> >> I suppose it depends on what people are going to do with RPKI. >> Today, RIR influence on routing is essentially advisory in nature >> -- if an address holder (say) fails to pay their address >> maintenance fee, RIRs can, at most, remove the address holder's >> blocks from whois databases. However, as I understand it, this has >> limited effect on existing contractual relationships between the >> address holders and the folks who already announce their space (it >> may have more effect on address holders who are attempting to find >> new ISPs to announce their space). The RIR could potentially >> reallocate the space, but this would likely be a good way of >> annoying multiple parties (not just the folks the address space was >> reclaimed from). > > Andrei's message acknoledged that address reclamation is a part of > RIR daily life. He did not explicitly mention For some class of address holders in some regions, I believe that reclamation is not possible (historical?). Are they outside of the scope of the RPKI? > re-allocation to a different party, but I can't imagine holding on > to unused address space, particularly in this current era of address- > shortage fears. > I suspect that the time from reclamation to deaggregation and reallocation will progressively grow smaller. >> >> If RPKI does not change this, then you're right -- there is not any >> more control. However, if filter lists are built or routers check >> origin authenticity in real-time by traversing the RPKI tree(s), > I think it goes deeper based on draft-pmohapat-sidr-pfx- validate-02.txt finding its way _into_ routers. > Those who build filter lists either rely on their customers' reports > or on IRR data, which is based on the RIR address allocations. I think Chris's past email regarding 216.239.63.0/24 suggests that the various IRRs aren't that tightly bound. Cheers Terry From terry.manderson@icann.org Thu Sep 17 21:06:27 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84BB13A6812 for ; Thu, 17 Sep 2009 21:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtEBVMXEEruo for ; Thu, 17 Sep 2009 21:06:26 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id D26163A6831 for ; Thu, 17 Sep 2009 21:06:26 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 17 Sep 2009 21:07:20 -0700 From: Terry Manderson To: Terry Manderson , George Michaelson , Sandra Murphy , Geoff Huston Date: Thu, 17 Sep 2009 21:07:18 -0700 Thread-Topic: [sidr] request to open document issue tracking Thread-Index: AcoyeZdEGCV5mcb/SA2OWaGyn89k7gAADj8aAWbsvB0= Message-ID: In-Reply-To: Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] request to open document issue tracking X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 04:06:27 -0000 Chairs, apologies for nagging, but this really is a good idea. Can this be implemented? Cheers Terry On 11/09/09 10:50 AM, "Terry Manderson" wrote: > I second that motion! >=20 > Terry >=20 >=20 > On 11/09/09 10:45 AM, "George Michaelson" wrote: >=20 >> Dear Working group chairs. >>=20 >> Please can we move to using the ietf tools issue tracker on the >> working group drafts. >>=20 >> I think this would help by clearly identifying issues. >>=20 >> -George >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From gih@apnic.net Thu Sep 17 22:49:13 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1058C3A68A0 for ; Thu, 17 Sep 2009 22:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rqu1aBd1Nv0Z for ; Thu, 17 Sep 2009 22:49:12 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 9663228C150 for ; Thu, 17 Sep 2009 22:49:02 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10] (unknown [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id CF6CCD58CE; Fri, 18 Sep 2009 15:53:22 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Geoff Huston In-Reply-To: Date: Fri, 18 Sep 2009 15:49:24 +1000 Content-Transfer-Encoding: 7bit Message-Id: <3F549424-3DC8-4E23-AD40-64227DC3BC93@apnic.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.1076) Cc: George Michaelson , "sidr@ietf.org" Subject: Re: [sidr] request to open document issue tracking X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 05:49:13 -0000 http://tools.ietf.org/wg/sidr/ On 18/09/2009, at 2:07 PM, Terry Manderson wrote: > > Chairs, > > apologies for nagging, but this really is a good idea. > > Can this be implemented? > > Cheers > Terry > > On 11/09/09 10:50 AM, "Terry Manderson" > wrote: > >> I second that motion! >> >> Terry >> >> >> On 11/09/09 10:45 AM, "George Michaelson" wrote: >> >>> Dear Working group chairs. >>> >>> Please can we move to using the ietf tools issue tracker on the >>> working group drafts. >>> >>> I think this would help by clearly identifying issues. >>> >>> -George >>> _______________________________________________ >>> 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 terry.manderson@icann.org Thu Sep 17 23:04:17 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F743A6A6D for ; Thu, 17 Sep 2009 23:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRxQhBqsQlGE for ; Thu, 17 Sep 2009 23:04:16 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id C0E683A6902 for ; Thu, 17 Sep 2009 23:04:16 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 17 Sep 2009 23:05:10 -0700 From: Terry Manderson To: Geoff Huston Date: Thu, 17 Sep 2009 23:05:08 -0700 Thread-Topic: [sidr] request to open document issue tracking Thread-Index: Aco4I+WvuehFTDjOTdeVloiFFb8NBAAAhONK Message-ID: In-Reply-To: <3F549424-3DC8-4E23-AD40-64227DC3BC93@apnic.net> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: George Michaelson , "sidr@ietf.org" Subject: Re: [sidr] request to open document issue tracking X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 06:04:17 -0000 http://trac.tools.ietf.org/wg/sidr/trac/report/1 T. On 18/09/09 3:49 PM, "Geoff Huston" wrote: > http://tools.ietf.org/wg/sidr/ >=20 > On 18/09/2009, at 2:07 PM, Terry Manderson wrote: >=20 >>=20 >> Chairs, >>=20 >> apologies for nagging, but this really is a good idea. >>=20 >> Can this be implemented? >>=20 >> Cheers >> Terry >>=20 >> On 11/09/09 10:50 AM, "Terry Manderson" >> wrote: >>=20 >>> I second that motion! >>>=20 >>> Terry >>>=20 >>>=20 >>> On 11/09/09 10:45 AM, "George Michaelson" wrote: >>>=20 >>>> Dear Working group chairs. >>>>=20 >>>> Please can we move to using the ietf tools issue tracker on the >>>> working group drafts. >>>>=20 >>>> I think this would help by clearly identifying issues. >>>>=20 >>>> -George >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 From Sandra.Murphy@cobham.com Fri Sep 18 05:05:58 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31DBC3A6967 for ; Fri, 18 Sep 2009 05:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ5c2+7JjO1X for ; Fri, 18 Sep 2009 05:05:57 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 45A7A3A6AB4 for ; Fri, 18 Sep 2009 05:05:57 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n8IC6oZf004419 for ; Fri, 18 Sep 2009 07:06:50 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n8IC6oOd004620 for ; Fri, 18 Sep 2009 07:06:50 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 08:06:50 -0400 Date: Fri, 18 Sep 2009 08:06:49 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 18 Sep 2009 12:06:50.0596 (UTC) FILETIME=[80FF1A40:01CA3858] Subject: Re: [sidr] FW: [rt.amsl.com #19593] tools site issue tracker for wg? (fwd) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 12:05:58 -0000 The tools team, specifically Henrik, has set up an issue tracker for sidr. >From Henrik's message: Tools site issue trackers are set up on a per-WG basis, and are set up on request for existing WGs. I've now set one up for sidr. There are links to the wiki and issue tracker on the WG's document status page; you can also reach the Trac environment directly at this URL: http://tools.ietf.org/wg/sidr/trac . --Sandy From Sandra.Murphy@cobham.com Fri Sep 18 05:19:05 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4413A684C for ; Fri, 18 Sep 2009 05:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrBiap3dzwfQ for ; Fri, 18 Sep 2009 05:19:04 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id D4AF73A6936 for ; Fri, 18 Sep 2009 05:18:44 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n8ICJaCd004506; Fri, 18 Sep 2009 07:19:36 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n8ICJZEI004976; Fri, 18 Sep 2009 07:19:36 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 08:19:35 -0400 Date: Fri, 18 Sep 2009 08:19:23 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <200909150416.n8F4GRN6068779@harbor.orleans.occnc.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 18 Sep 2009 12:19:35.0586 (UTC) FILETIME=[48F75020:01CA385A] Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 12:19:05 -0000 Curtis was suggesting if address space is not as cheap as domain names, then this scheme would not be used. I picked up on the point that the RPKI does not effect address allocation fees. Which it doesn't. But Randy has addressed Curtis's point more accurately, as Curtis was speaking of the RPKI as if it were a registry, so his comment about pricing was probably directed to certs, not addresses. I would hope that the RIRs would not charge for certs separately from charging fees for address allocations. The RPKI will work best if *ALL* address allocations have a corresponding cert. If that turns out to be a cost to the recipient, we're likely to see people who choose not to get the corresponding cert. That would IMHO be a bad thing. --Sandy On Fri, 18 Sep 2009, Randy Bush wrote: >> Prices for address allocations are not affected by the RPKI. > > given that at least some RIRs are exploring how and what to charge for > certs, this is a bit naive. > > randy > From Sandra.Murphy@cobham.com Fri Sep 18 06:13:44 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436E13A691D for ; Fri, 18 Sep 2009 06:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUhoZEnuU+Mi for ; Fri, 18 Sep 2009 06:13:43 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 27A5C3A6852 for ; Fri, 18 Sep 2009 06:13:40 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n8IDE9nb005173; Fri, 18 Sep 2009 08:14:09 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n8IDE8d6006733; Fri, 18 Sep 2009 08:14:09 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 09:14:07 -0400 Date: Fri, 18 Sep 2009 09:08:22 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Terry Manderson In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 18 Sep 2009 13:14:08.0122 (UTC) FILETIME=[E78CADA0:01CA3861] Cc: George Michaelson , "sidr@ietf.org" Subject: Re: [sidr] request to open document issue tracking X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 13:13:44 -0000 Yes, Terry spotted the new issue tracker before I got to the message from the tools team saying it was up. Besides the direct URL to the tracker, there is now an "Issues" link on the top line of the sidr status pages http://tools.ietf.org/wg/sidr/. That top line now also contains a link to a sidr wiki: http://trac.tools.ietf.org/wg/sidr/trac/wiki --Sandy On Thu, 17 Sep 2009, Terry Manderson wrote: > http://trac.tools.ietf.org/wg/sidr/trac/report/1 > > T. > > > On 18/09/09 3:49 PM, "Geoff Huston" wrote: > >> http://tools.ietf.org/wg/sidr/ >> >> On 18/09/2009, at 2:07 PM, Terry Manderson wrote: >> >>> >>> Chairs, >>> >>> apologies for nagging, but this really is a good idea. >>> >>> Can this be implemented? >>> >>> Cheers >>> Terry >>> >>> On 11/09/09 10:50 AM, "Terry Manderson" >>> wrote: >>> >>>> I second that motion! >>>> >>>> Terry >>>> >>>> >>>> On 11/09/09 10:45 AM, "George Michaelson" wrote: >>>> >>>>> Dear Working group chairs. >>>>> >>>>> Please can we move to using the ietf tools issue tracker on the >>>>> working group drafts. >>>>> >>>>> I think this would help by clearly identifying issues. >>>>> >>>>> -George >>>>> _______________________________________________ >>>>> 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 kent@bbn.com Fri Sep 18 10:27:04 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E847D3A6AD2 for ; Fri, 18 Sep 2009 10:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3IX1WfMpvUQ for ; Fri, 18 Sep 2009 10:27:04 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E03FB3A6B3B for ; Fri, 18 Sep 2009 10:27:03 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MohFU-0005YT-Ah; Fri, 18 Sep 2009 13:27:56 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <82841276-06EC-4A20-A26A-1FA75BCF7E5E@terrym.net> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> <82841276-06EC-4A20-A26A-1FA75BCF7E5E@terrym.net> Date: Fri, 18 Sep 2009 13:23:33 -0400 To: Terry Manderson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 17:27:05 -0000 At 12:32 PM +1000 9/18/09, Terry Manderson wrote: >Hi Steve, > >On 17/09/2009, at 1:53 AM, Stephen Kent wrote: >> >>In the local TA management scheme I described, an RP gets to >>specify the set of resources it believes is associated with a given >>key (cert). The software enables an RP to assert what it "knows" to >>be true, overriding what the > >"knows" == "believes" ;-) yes, believes is more accurate, but that's why I put the "knows" in quotes :-). > >>repositories and the putative TAs may assert. So, if there is a >>conflict relative to the info that the RP says it knows to be true, >>what the RP says it knows to be true prevails (locally). If the >>conflict arises at a point that is below a cert that the RP ad >>adopted as a TA, and if the RP has no other info about the >>resources in question, then no, the software can't help with such a >>problem problem. > >right, so the software isn't currently intended to traverse the >'assimilated relying party rpki' to pick out conflicts. nor >highlight that in terms of the TA set chosen by the relying party. >(I'm saying that is a deficiency, just thinking aloud) We were told over a year ago that, because of legitimate transfers, looking for duplicates was bad idea, in the repository system. So, I'm not sure if we want to do it in the 'assimilated relying party rpki.' > >> >>I think references to the IANA->RIR->... hierarchy are appropriate >>for describing the extant allocation process. Moreover, it is >>appropriate to note that the RPKI is designed to mimic that >>hierarchy. It is also important to note that the choice of TAs is >>always a local matter. If folks want, I can prepare an >>(informational) I-D that describes one way of managing TA locally, >>as per my presentation at the SIDR meeting. > >I think I would like to see such an I-D. OK, we'll look into generating one. > >>> >>>Sure. But if we are looking for a qualitative trust statement of >>>TAs, where does one look? Or don't we? Is this just not a problem >>>to care about? >> >>Statements about perceived trust in TAs are useful in PKIs that >>anoint 3rd parties as TAs, independent of real world authorization. >>The RPLI is not such a PKI. Instead it seeks to have the real world >>entities that manage allocation of resources act as CAs. I would >>urge us to NOT try to make the RPKI into a trusted 3rd party PKI. >> > >while I agree the intent isn't to make a 3rd party PKI, won't that >happen anyway? At least I see it as likely, irrespective of the >allocation resource hierarchy. One cannot prevent 3rd parties from asserting themselves as TAs, but the CP does not accommodate such entities as CAs, nor does the repository system facilitate their use. The local TA management proposal deals only with LOCAL perceptions of TAs. If an organization wants to promote it's (local) view of TAs to others, it is up to that entity to develop the necessary tools to do so, and to convince others to make use of these tools. I think that represents a reasonable tradeoff between allowing local TA management and encouraging 3rd party TAs. Steve From curtis@occnc.com Sat Sep 19 16:02:29 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471773A6987 for ; Sat, 19 Sep 2009 16:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiMaBBCdH3BL for ; Sat, 19 Sep 2009 16:02:28 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 558133A696F for ; Sat, 19 Sep 2009 16:02:28 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id n8JN3CAV052872; Sat, 19 Sep 2009 19:03:12 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <200909192303.n8JN3CAV052872@harbor.orleans.occnc.com> To: Stephen Kent From: Curtis Villamizar In-reply-to: Your message of "Tue, 15 Sep 2009 09:02:25 EDT." Date: Sat, 19 Sep 2009 19:03:12 -0400 Sender: curtis@occnc.com Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 23:02:29 -0000 In message Stephen Kent writes: > > At 12:22 AM -0400 9/15/09, Curtis Villamizar wrote: > >In message <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> > >John Schnizlein writes: > >> > >> David, > >> > >> What you may be looking for is Steve Kent's Trust Anchor Management > >> presentation (and the errata slide 13) - the last items in the SIDR > >> materials from IETF 75. > >> > >> https://datatracker.ietf.org/meeting/75/materials.html > >> > >> John > > > > > >Its in a vendor proprietary format. > > > >Never trust anyone that uses vendor proprietary formats. :-) > > > >Curtis > > Oh, I am soooo hurt. Would PDF be OK, despite it's proprietary > nature? If you require ASCII art you'll have a very long wait :-). > > Steve Steve, PDF is fine. Curtis From curtis@occnc.com Sat Sep 19 17:44:10 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4034C3A680E for ; Sat, 19 Sep 2009 17:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gmpWzcSBA7J for ; Sat, 19 Sep 2009 17:44:09 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 3F1B53A63EB for ; Sat, 19 Sep 2009 17:44:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id n8K0j5Pi054023; Sat, 19 Sep 2009 20:45:05 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <200909200045.n8K0j5Pi054023@harbor.orleans.occnc.com> To: Sandra Murphy From: Curtis Villamizar In-reply-to: Your message of "Fri, 18 Sep 2009 08:19:23 EDT." Date: Sat, 19 Sep 2009 20:45:05 -0400 Sender: curtis@occnc.com Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 00:44:10 -0000 In message Sandra Murphy writes: > > Curtis was suggesting if address space is not as cheap as domain names, > then this scheme would not be used. Truly competitive and/or reasonably priced would be a more accurate translation of "like domain names". > I picked up on the point that the RPKI does not effect address allocation > fees. Which it doesn't. There is an odd problem with address allocation (that might also be out of scope for SIDR). If there are multiple places to get addresses from (truly competitive) then aggregation may be affected. Perhaps having a small number but more than one within a geographic region would serve both goals. This does not affect the PKI. > But Randy has addressed Curtis's point more accurately, as Curtis was > speaking of the RPKI as if it were a registry, so his comment about > pricing was probably directed to certs, not addresses. At the top level address allocation and registry are the same thing. So if certs are issued with addresses CA and registry is the same at that level. [We are going down a politically charged rat hole.] > I would hope that the RIRs would not charge for certs separately from > charging fees for address allocations. The RPKI will work best if *ALL* > address allocations have a corresponding cert. If that turns out to be a > cost to the recipient, we're likely to see people who choose not to get > the corresponding cert. That would IMHO be a bad thing. Free cert with your address would be nice. A reasonable price would be acceptable. Again, a layer 8 problem. And out of scope. Sorry. > --Sandy Curtis > On Fri, 18 Sep 2009, Randy Bush wrote: > > >> Prices for address allocations are not affected by the RPKI. > > > > given that at least some RIRs are exploring how and what to charge for > > certs, this is a bit naive. > > > > randy From randy@psg.com Sat Sep 19 20:55:57 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19A33A68C9 for ; Sat, 19 Sep 2009 20:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4q0Rny1-B3f for ; Sat, 19 Sep 2009 20:55:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 29B9D3A68CF for ; Sat, 19 Sep 2009 20:55:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MpDXf-000Eq6-03; Sun, 20 Sep 2009 03:56:51 +0000 Received: from h041n073.wl17.iiji.jp.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id AE08D2AA72E8; Sun, 20 Sep 2009 12:56:48 +0900 (JST) Date: Sun, 20 Sep 2009 12:56:48 +0900 Message-ID: From: Randy Bush To: Curtis Villamizar In-Reply-To: <200909200045.n8K0j5Pi054023@harbor.orleans.occnc.com> References: <200909200045.n8K0j5Pi054023@harbor.orleans.occnc.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 03:55:58 -0000 > Free cert with your address would be nice. A reasonable price would > be acceptable. expiration and revocation are serious issues and, as the rirs' claws continue to uncloak, a very serious worry. randy From Sandra.Murphy@cobham.com Sun Sep 20 03:33:05 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6DF03A6784 for ; Sun, 20 Sep 2009 03:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDecULavw37T for ; Sun, 20 Sep 2009 03:33:04 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B1B2C3A682C for ; Sun, 20 Sep 2009 03:33:04 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n8KAY2PF029816; Sun, 20 Sep 2009 05:34:02 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n8KAY22p020485; Sun, 20 Sep 2009 05:34:02 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 20 Sep 2009 06:34:01 -0400 Date: Sun, 20 Sep 2009 06:34:01 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Curtis Villamizar In-Reply-To: <200909200045.n8K0j5Pi054023@harbor.orleans.occnc.com> Message-ID: References: <200909200045.n8K0j5Pi054023@harbor.orleans.occnc.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 20 Sep 2009 10:34:01.0965 (UTC) FILETIME=[DEA8F1D0:01CA39DD] Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 10:33:06 -0000 On Sat, 19 Sep 2009, Curtis Villamizar wrote: > > In message > Sandra Murphy writes: >> >> Curtis was suggesting if address space is not as cheap as domain names, >> then this scheme would not be used. > > Truly competitive and/or reasonably priced would be a more accurate > translation of "like domain names". > >> I picked up on the point that the RPKI does not effect address allocation >> fees. Which it doesn't. > > There is an odd problem with address allocation (that might also be > out of scope for SIDR). If there are multiple places to get addresses > from (truly competitive) then aggregation may be affected. Perhaps > having a small number but more than one within a geographic region > would serve both goals. This does not affect the PKI. > >> But Randy has addressed Curtis's point more accurately, as Curtis was >> speaking of the RPKI as if it were a registry, so his comment about >> pricing was probably directed to certs, not addresses. > > At the top level address allocation and registry are the same thing. > So if certs are issued with addresses CA and registry is the same at > that level. [We are going down a politically charged rat hole.] > >> I would hope that the RIRs would not charge for certs separately from >> charging fees for address allocations. The RPKI will work best if *ALL* >> address allocations have a corresponding cert. If that turns out to be a >> cost to the recipient, we're likely to see people who choose not to get >> the corresponding cert. That would IMHO be a bad thing. > > Free cert with your address would be nice. A reasonable price would > be acceptable. Again, a layer 8 problem. If it is a price paid by an increased cost to an allocation, that's one thing. If it is a price paid by opting in to an optional feature, that's very different, and unpleasant in impact to the RPKI. Not our business to argue the price model, but the impact is. > And out of scope. Sorry. The problems of partial deployment (not everyone has a cert for their address) are within scope for the wg, I'd say. There might be different ways of dealing with partial deployment when it was viewed as a temporary problem (eventually everone will covert from BGP3 to BGP4, etc) versus when it was viewed as a permanent condition and too common to be dismissed. --Sandy > >> --Sandy > > Curtis > > >> On Fri, 18 Sep 2009, Randy Bush wrote: >> >>>> Prices for address allocations are not affected by the RPKI. >>> >>> given that at least some RIRs are exploring how and what to charge for >>> certs, this is a bit naive. >>> >>> randy > From tvest@eyeconomics.com Sun Sep 20 07:29:21 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8D33A6949 for ; Sun, 20 Sep 2009 07:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j-iRcNRnNH6 for ; Sun, 20 Sep 2009 07:29:20 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 4D2173A6914 for ; Sun, 20 Sep 2009 07:29:20 -0700 (PDT) Received: from OMTA19.westchester.pa.mail.comcast.net ([76.96.62.98]) by QMTA02.westchester.pa.mail.comcast.net with comcast id j2KD1c00127AodY522WLUw; Sun, 20 Sep 2009 14:30:20 +0000 Received: from [172.16.1.4] ([24.125.119.130]) by OMTA19.westchester.pa.mail.comcast.net with comcast id j2bM1c0012otf883f2bMBd; Sun, 20 Sep 2009 14:35:21 +0000 From: tvest@eyeconomics.com To: Randy Bush In-Reply-To: References: <200909200045.n8K0j5Pi054023@harbor.orleans.occnc.com> Message-Id: <443CDC1D-68A5-470B-B7A6-9C48BA177F90@eyeconomics.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 20 Sep 2009 10:30:18 -0400 X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 14:29:21 -0000 On Sep 19, 2009, at 11:56 PM, Randy Bush wrote: >> Free cert with your address would be nice. A reasonable price would >> be acceptable. > > expiration and revocation are serious issues and, as the rirs' claws > continue to uncloak, a very serious worry. > > randy Hi Randy, You've been making cryptic comments like this, about RIR misfeasance/ malfeasance, for over two years now (or at least that's when I first noticed them). Could you explain what you mean, exactly, and what this worry is based on, specifically? Thanks, Tom From randy@psg.com Sun Sep 20 07:46:23 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2940D3A67F5 for ; Sun, 20 Sep 2009 07:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G-gIPU01LY2 for ; Sun, 20 Sep 2009 07:46:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 420CA3A67F2 for ; Sun, 20 Sep 2009 07:46:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MpNh8-0007yh-Ru; Sun, 20 Sep 2009 14:47:19 +0000 Received: from h041n073.wl17.iiji.jp.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 9ED902AA8EE5; Sun, 20 Sep 2009 23:47:16 +0900 (JST) Date: Sun, 20 Sep 2009 23:47:16 +0900 Message-ID: From: Randy Bush To: tvest@eyeconomics.com In-Reply-To: <443CDC1D-68A5-470B-B7A6-9C48BA177F90@eyeconomics.com> References: <200909200045.n8K0j5Pi054023@harbor.orleans.occnc.com> <443CDC1D-68A5-470B-B7A6-9C48BA177F90@eyeconomics.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 14:46:23 -0000 > You've been making cryptic comments like this, about RIR misfeasance/ > malfeasance, for over two years now (or at least that's when I first > noticed them). excuse. please show where i have alledged malfeasance. otherwise, do not put words in my keyboard. randy From tvest@eyeconomics.com Sun Sep 20 08:34:53 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ECB93A67D7 for ; Sun, 20 Sep 2009 08:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtpUndkKV3-N for ; Sun, 20 Sep 2009 08:34:52 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 5F80B3A67F5 for ; Sun, 20 Sep 2009 08:34:52 -0700 (PDT) Received: from OMTA24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA05.westchester.pa.mail.comcast.net with comcast id j3DJ1c0051ei1Bg553bspN; Sun, 20 Sep 2009 15:35:52 +0000 Received: from [172.16.1.4] ([24.125.119.130]) by OMTA24.westchester.pa.mail.comcast.net with comcast id j3hA1c0032otf883k3hAFT; Sun, 20 Sep 2009 15:41:11 +0000 From: tvest@eyeconomics.com To: Randy Bush In-Reply-To: <443CDC1D-68A5-470B-B7A6-9C48BA177F90@eyeconomics.com> References: <200909200045.n8K0j5Pi054023@harbor.orleans.occnc.com> <443CDC1D-68A5-470B-B7A6-9C48BA177F90@eyeconomics.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 20 Sep 2009 11:35:50 -0400 X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 15:34:53 -0000 > On Sep 20, 2009, at 10:30 AM, tvest@eyeconomics.com wrote: > >> >> On Sep 19, 2009, at 11:56 PM, Randy Bush wrote: >> >>>> Free cert with your address would be nice. A reasonable price >>>> would >>>> be acceptable. >>> >>> expiration and revocation are serious issues and, as the rirs' claws >>> continue to uncloak, a very serious worry. >>> >>> randy >> >> Hi Randy, >> >> You've been making cryptic comments like this, about RIR >> misfeasance/malfeasance, for over two years now (or at least that's >> when I first noticed them). >> Could you explain what you mean, exactly, and what this worry is >> based on, specifically? >> >> Thanks, >> >> Tom >> > > On Sep 20, 2009, at 10:47 AM, Randy Bush wrote: > > excuse. please show where i have alledged malfeasance. otherwise, do > not put words in my keyboard. > > randy I should have known better than to provide such an easy diversionary option ;-) If I mischaracterized your views, please accept my sincere apologies. Allow me to rephrase: 1. Which RIR "claws" are you referring to, exactly? 2. How have those claws been "cloaked" to date, specifically, and what's enabling you to see through that cloak more clearly now? 3. What is the exact nature of the "very serious worry" that this development has instilled in you? Thanks, TV From jis@jis.tzo.com Sun Sep 20 09:21:19 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1053A67F5 for ; Sun, 20 Sep 2009 09:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nuql0zcm+CKm for ; Sun, 20 Sep 2009 09:21:18 -0700 (PDT) Received: from jis.tzo.com (JISVPN1.MIT.EDU [18.4.26.20]) by core3.amsl.com (Postfix) with ESMTP id 596203A67CC for ; Sun, 20 Sep 2009 09:21:17 -0700 (PDT) Received: by jis.tzo.com (Postfix, from userid 435) id 5F7AE34DAD; Sun, 20 Sep 2009 12:22:16 -0400 (EDT) Date: Sun, 20 Sep 2009 12:22:16 -0400 From: "Jeffrey I. Schiller" To: David Conrad Message-ID: <20090920162216.GB11512@mit.edu> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <46649EB3-A2C1-438B-91CA-CAF17130C1A8@virtualized.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="JYK4vJDZwFMowpUq" Content-Disposition: inline In-Reply-To: <46649EB3-A2C1-438B-91CA-CAF17130C1A8@virtualized.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 16:21:19 -0000 --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I had a hard time figuring out where to =E2=80=9Cchain=E2=80=9D this messag= e, so I stuck it here... Let=E2=80=99s take a step back please. What is the purpose of RPKI/SIDR? Is it to enforce allocation policies? Or is it to prevent =E2=80=9Cbad guys=E2=80=9D from spoofing rout= ing advertisements for the purpose of various forms of malfeasance? I do believe these are separate problems. If it is for enforcing allocation policies, it effects the balance of power between the various actors. Today if there is a legal dispute between an allocator and an organization with an allocation, it will be solved through existing civil means. This may take some time. In the meantime the status quo continues (from a technical/operational perspective). With RPKI the allocator can revoke the organizations certificate, while the civil process takes its time, causing harm to the organization that is now un-routable. Don=E2=80=99t think they won=E2= =80=99t do the revocation. I have personally seen situations where if one party has =E2=80=9Cthe switch=E2=80=9D to enforce their will, they use it. On the other hand if it is to prevent =E2=80=9Cbad guys=E2=80=9D from spoof= ing routing, then the trick is to design it so that is doesn=E2=80=99t effect t= he balance of power between the various *legitimate* actors. Judging from the conversations I have seen, I suspect we don=E2=80=99t have a system that doesn=E2=80=99t effect the balance of power. In my opinion, it is a good idea to work on not changing the balance of power. That may require that the allocation agencies *not* be part of the key hierarchy. -Jeff -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --JYK4vJDZwFMowpUq Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIoAYJKoZIhvcNAQcCoIIIkTCCCI0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BhcwggLQMIICOaADAgECAhA7rjDxaPCv6xqNpf+C9MOcMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA1MTQxMzI3 MjZaFw0xMDA1MTQxMzI3MjZaMD0xHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx GjAYBgkqhkiG9w0BCQEWC2ppc0BtaXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA9IJotg2DKDd6bFs3F1Tlz0bolVWtqVlss7UZCyjh2b2Gbuge/Qe2sUexvauzMnu9 CvbM8BV3Msgu+F3NacfdG5iu0p0BHpUjdiyQ4MG8OmBuuvJ+UABqKP3oGRt/yzOilEHJyMzu rS3etIOjjr3IVGNMRzapoxXdBSdFUdFXUGWeAfi+hE5FPR+q3Tq1bgd/HjTvpJTc1emPQ5C8 v3pPD23gsAn1vMwSG9bxAPoEmp7YWmsVGpt4Bs2xQtKE1Gph5/znaDhl+S7Ipx3PZ09ZvfbI NRFImahDHwu0duRiPZPeaCMa3hI+hF6DDg7U7zU8l9sVW2QSifcqce6e08L7PwIDAQABoygw JjAWBgNVHREEDzANgQtqaXNAbWl0LmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAKuMzXB+BF3P7v6+4PvYS8V+9Kh19gWXyHSxvt0UX5LBub53kVmATU1CcJyd59jovoOj CHubIgWLGPmXQ2H0FJhwvM6/KyNuzpgUGfaPrVVb+/w4RFWMuVrxZuqqipNl6eT6/Smzx9kd cLVtTNkbVkWB7/aW2cyMqouhe6JNGa0OMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAlEw ggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA7rjDxaPCv6xqNpf+C9MOcMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTIwMTYyMjE2WjAjBgkqhkiG9w0BCQQxFgQUYwCn SMKzEIO6md/VxduiInX4kjcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEggEAqvCijtil9LVTGDCbxACtF5bUqnT2lRWytSrX7IkZoFcbDg8erIilQeYD RReaxWPmTdJgpKwcvcpBdntkrSGl17bNGo1iJL+KAIyqZzZr8nnqxGgqUUatZFV+OJnrUkHW Y6njI7sKvw9/qre8e6vDa18414/dky7NEWnxI1fYo+c/QMgJsDObcPH3CWbGiEZhT1qVSk8c Euo4FNDXBqe97oPDPmwPlKfgDeylfM4I7sGmi3beEaO5Zs6jDAGcpP1AxebgWnYAbzNk0/MH 0LZ5oFlmerZnZSskzJa7X02n/iXI2CwxbeVKQxb3pcI4bfAZ0WQOVCft7JDKd0ft8jSfpw== --JYK4vJDZwFMowpUq-- From terry.mndrsn@gmail.com Sun Sep 20 23:15:10 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B233A67E3 for ; Sun, 20 Sep 2009 23:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dgu8g8mAGa8F for ; Sun, 20 Sep 2009 23:15:08 -0700 (PDT) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 355193A683B for ; Sun, 20 Sep 2009 23:15:08 -0700 (PDT) Received: by ywh15 with SMTP id 15so3251723ywh.5 for ; Sun, 20 Sep 2009 23:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=GR7+Gog6yrOEx2zunu8r/ppEXkITqlL+0RrhXrQwBSk=; b=egCaWaDicOr2W7kUZhkxISDqLrj1yWaxsnBzBC3jC5zqbw9EDBcg5KdqeaM89xo75Q vDpTovjRfPIYT4y0HD4hfCD5G3Ppv9FnX0JIyM3Rm1qrqr/5WuvW+z6emGniqarFe4tX JN3SNP+z/md5fRM5z7/zjIG0Ugx2IozhGQuho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MvHfEhDcypAjXjnMog80IYQKyXYp2aneF/+spj+5pPGWUZ4DssBmCQdDhi2bjmINPA 9ck1AG832CHf5zsa/oOBSGvWUFljf/Cuja1vpdu8sKRa4Rv6bBATewzfAe0UXKjT9af/ r4oUU0NYohcXAqv37zaGdmOhvz4N7KsJDDSas= Received: by 10.151.5.19 with SMTP id h19mr7574709ybi.264.1253513766268; Sun, 20 Sep 2009 23:16:06 -0700 (PDT) Received: from ?192.168.1.103? ([114.77.128.245]) by mx.google.com with ESMTPS id 20sm1814896ywh.14.2009.09.20.23.16.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 20 Sep 2009 23:16:05 -0700 (PDT) Sender: Terry Manderson Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Terry Manderson In-Reply-To: Date: Mon, 21 Sep 2009 16:15:59 +1000 Content-Transfer-Encoding: 7bit Message-Id: <1DBB285F-BFEA-4AF3-9544-FD780C5B3684@terrym.net> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> <82841276-06EC-4A20-A26A-1FA75BCF7E5E@terrym.net> To: Stephen Kent X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 06:15:10 -0000 On 19/09/2009, at 3:23 AM, Stephen Kent wrote: > > We were told over a year ago that, because of legitimate transfers, > looking for duplicates was bad idea, in the repository system. So, > I'm not sure if we want to do it in the 'assimilated relying party > rpki.' > So legitimate transfers will breed duplicates? My recollection of that discussion that there would be timing in place that certificate validity times would be tuned (with sparse use of CRLs) to effect the transfers. Or am I mistaken? I think, if anywhere you needed to go looking for duplicates it would be the relying party software (either your software or rcynic) before it mades it to the router "decision" > > OK, we'll look into generating one. > :-) > > One cannot prevent 3rd parties from asserting themselves as TAs, but > the CP does not accommodate such entities as CAs, nor does the > repository system facilitate their use. If your software can change the contents of the 3779 extensions, would it not be a simple exercise to change the SIA value? Cheers Terry From dol@cryptocom.ru Mon Sep 21 04:23:36 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 885323A6765 for ; Mon, 21 Sep 2009 04:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSqefMoT6HHk for ; Mon, 21 Sep 2009 04:23:35 -0700 (PDT) Received: from mx.cryptocom.ru (mx.cryptocom.ru [87.245.158.60]) by core3.amsl.com (Postfix) with ESMTP id 63FBC3A6A7E for ; Mon, 21 Sep 2009 04:23:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 4CEF63EC12; Mon, 21 Sep 2009 15:24:35 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6rdrPPSrQZES; Mon, 21 Sep 2009 15:24:35 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id BFAAC3EC0F; Mon, 21 Sep 2009 15:24:34 +0400 (MSD) Message-ID: <4AB76272.2090206@cryptocom.ru> Date: Mon, 21 Sep 2009 15:24:34 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Stephen Kent References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 11:23:36 -0000 Stephen Kent пишет: > If > folks want, I can prepare an (informational) I-D that describes_ one_ > way of managing TA locally, as per my presentation at the SIDR meeting. Folks want. It would be a nice reference point and would save a lot of explanations in future deployment. dol@ From Sandra.Murphy@cobham.com Mon Sep 21 07:41:03 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8256E3A6A87 for ; Mon, 21 Sep 2009 07:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyxtwY80-XHQ for ; Mon, 21 Sep 2009 07:41:02 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 711073A6901 for ; Mon, 21 Sep 2009 07:41:02 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n8LEg2Qd005993; Mon, 21 Sep 2009 09:42:02 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n8LEg2I5012920; Mon, 21 Sep 2009 09:42:02 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 10:42:01 -0400 Date: Mon, 21 Sep 2009 10:41:58 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Jeffrey I. Schiller" In-Reply-To: <20090920162216.GB11512@mit.edu> Message-ID: References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <46649EB3-A2C1-438B-91CA-CAF17130C1A8@virtualized.org> <20090920162216.GB11512@mit.edu> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="329208676-24920-1253544118=:1564" X-OriginalArrivalTime: 21 Sep 2009 14:42:02.0105 (UTC) FILETIME=[AE53DE90:01CA3AC9] Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 14:41:03 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --329208676-24920-1253544118=:1564 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 20 Sep 2009, Jeffrey I. Schiller wrote: > I had a hard time figuring out where to =E2=80=9Cchain=E2=80=9D this mess= age, so I > stuck it here... > > Let=E2=80=99s take a step back please. > > What is the purpose of RPKI/SIDR? Is it to enforce allocation > policies? Or is it to prevent =E2=80=9Cbad guys=E2=80=9D from spoofing ro= uting > advertisements for the purpose of various forms of malfeasance? I don't believe that any one is trying to enforce allocation policies.=20 Policies are not mentioned at all in the PRKI. Certainly allocation actions are embodied in the RPKI, but not the=20 policies that guided them. > > I do believe these are separate problems. > > If it is for enforcing allocation policies, it effects the balance of > power between the various actors. Today if there is a legal dispute > between an allocator and an organization with an allocation, it will > be solved through existing civil means. This may take some time. In > the meantime the status quo continues (from a technical/operational > perspective). With RPKI the allocator can revoke the organizations > certificate, while the civil process takes its time, causing harm to > the organization that is now un-routable. Don=E2=80=99t think they won=E2= =80=99t do > the revocation. I have personally seen situations where if one party > has =E2=80=9Cthe switch=E2=80=9D to enforce their will, they use it. > > On the other hand if it is to prevent =E2=80=9Cbad guys=E2=80=9D from spo= ofing > routing, then the trick is to design it so that is doesn=E2=80=99t effect= the > balance of power between the various *legitimate* actors. Judging from > the conversations I have seen, I suspect we don=E2=80=99t have a system t= hat > doesn=E2=80=99t effect the balance of power. > > In my opinion, it is a good idea to work on not changing the balance > of power. That may require that the allocation agencies *not* be part > of the key hierarchy. We decided way back that the authorization to originate a route to a=20 prefix must come from the prefix holder. And that identification of a=20 prefix holder comes from the entity that allocated the prefix. Which decision are you recommending that we change - that we find a source= =20 of authorization to originate routes to a prefix *other than* the prefix=20 holder? Or that we find a way to identify the prefix holder *other than* through=20 the entity that allocated them the prefix? --Sandy > > -Jeff > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Jeffrey I. Schiller > MIT Network Manager > Information Services and Technology > Massachusetts Institute of Technology > 77 Massachusetts Avenue Room W92-190 > Cambridge, MA 02139-4307 > 617.253.0161 - Voice > jis@mit.edu > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --329208676-24920-1253544118=:1564-- From jis@jis.tzo.com Mon Sep 21 08:01:02 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109AE28C119 for ; Mon, 21 Sep 2009 08:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK8FCPyFuC5v for ; Mon, 21 Sep 2009 08:01:01 -0700 (PDT) Received: from jis.tzo.com (JISVPN1.MIT.EDU [18.4.26.20]) by core3.amsl.com (Postfix) with ESMTP id 16DC028C104 for ; Mon, 21 Sep 2009 08:01:00 -0700 (PDT) Received: by jis.tzo.com (Postfix, from userid 435) id E869434DAD; Mon, 21 Sep 2009 11:02:01 -0400 (EDT) Date: Mon, 21 Sep 2009 11:02:01 -0400 From: "Jeffrey I. Schiller" To: Sandra Murphy Message-ID: <20090921150201.GD10601@mit.edu> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <46649EB3-A2C1-438B-91CA-CAF17130C1A8@virtualized.org> <20090920162216.GB11512@mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="n2Pv11Ogg/Ox8ay5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 15:01:02 -0000 --n2Pv11Ogg/Ox8ay5 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 21, 2009 at 10:41:58AM -0400, Sandra Murphy wrote: > We decided way back that the authorization to originate a route to a > prefix must come from the prefix holder. And that identification of > a prefix holder comes from the entity that allocated the prefix. Who is the =E2=80=9CWe=E2=80=9D in this case? If it is the working group, t= hen I suggest that a broader consensus is required. The problem with hierarchies is that people then assume that they are strict. The guy =E2=80=9Chigher up=E2=80=9D is =E2=80=9Cin charge=E2=80=9D = and the guy lower down can do nothing but accept what is promulgated. In the real world, things are quite different. Sure, allocations are initially made by an appropriate registry. However some allocations pre-date the existing registration system and exactly where they sit is unclear. Then there are business disputes that always occur. My point is that adding RPKI can change the dynamics of these interactions, and not necessarily in a good way. I believe we need a solution which provides =E2=80=9Csecurity=E2=80=9D agai= nst bad actors while minimizing the impact on the business dynamics. I purposely didn=E2=80=99t propose a solution, but I can... Perhaps the RPKI CA=E2=80=99s should explicitly *not* be the registration authorities (or perhaps they can be, but that there should also be a non-affiliated CA that can issue trusted certificates). Much like it is today with web site certificates. The CA=E2=80=99s do *not* have to be the DNS registrars for the domain name. Instead the CA uses WHOIS data to determine if it is appropriate to issue a particular certificate. Similarly an RPKI CA can consult WHOIS data (or radb data) to determine the information it needs to issue a certificate. In this fashion if a dispute happens between the registration authority and the customer, the registration authority cannot use certificate revocation (or failure to renew a certificate) as a =E2=80=9Cto= ol=E2=80=9D to enhance its negotiating position. Keep in mind that just because an organization is a registration authority, doesn=E2=80=99t mean that in a gi= ven dispute it is =E2=80=9Cright=E2=80=9D automatically! As Hagrid said: =E2=80= =9CNot all wizards are good!=E2=80=9D (sorry, couldn=E2=80=99t help myself :-) ). -Jeff P.S. I am not claiming that the solution I propose is the only one, or even the best one, but I believe it impacts the business relationships between the registration authorities and their customers less then if the registration authorities were also the CA=E2=80=99s (or otherwise in a position to fail to renew a certificate or revoke an existing certificate). -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --n2Pv11Ogg/Ox8ay5 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIoAYJKoZIhvcNAQcCoIIIkTCCCI0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BhcwggLQMIICOaADAgECAhA7rjDxaPCv6xqNpf+C9MOcMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA1MTQxMzI3 MjZaFw0xMDA1MTQxMzI3MjZaMD0xHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx GjAYBgkqhkiG9w0BCQEWC2ppc0BtaXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA9IJotg2DKDd6bFs3F1Tlz0bolVWtqVlss7UZCyjh2b2Gbuge/Qe2sUexvauzMnu9 CvbM8BV3Msgu+F3NacfdG5iu0p0BHpUjdiyQ4MG8OmBuuvJ+UABqKP3oGRt/yzOilEHJyMzu rS3etIOjjr3IVGNMRzapoxXdBSdFUdFXUGWeAfi+hE5FPR+q3Tq1bgd/HjTvpJTc1emPQ5C8 v3pPD23gsAn1vMwSG9bxAPoEmp7YWmsVGpt4Bs2xQtKE1Gph5/znaDhl+S7Ipx3PZ09ZvfbI NRFImahDHwu0duRiPZPeaCMa3hI+hF6DDg7U7zU8l9sVW2QSifcqce6e08L7PwIDAQABoygw JjAWBgNVHREEDzANgQtqaXNAbWl0LmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAKuMzXB+BF3P7v6+4PvYS8V+9Kh19gWXyHSxvt0UX5LBub53kVmATU1CcJyd59jovoOj CHubIgWLGPmXQ2H0FJhwvM6/KyNuzpgUGfaPrVVb+/w4RFWMuVrxZuqqipNl6eT6/Smzx9kd cLVtTNkbVkWB7/aW2cyMqouhe6JNGa0OMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAlEw ggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA7rjDxaPCv6xqNpf+C9MOcMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTIxMTUwMjAxWjAjBgkqhkiG9w0BCQQxFgQUfz3R fD3Ud9fwopi5ycCnTNvxnpwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEggEALRMA7Xo3fpYP/G7KOzeo447RoJGh8cE2apu1YK/s5kMrKTydr77zSyAo 5SM9AyPhI5d/1LWv1F4uf2qmHEvvkvBlF4k51Bdr261GcyCM0QanNDRI9gSIv3cx3D6fuHQi Yrv6siY0AvdG+IVhnQGD8kGhiGS4m7gp8LsxEPYCoGDfdf3fLMXr/PccclYSeo47ZGuCoYBx uDKxe3Ltg0CkUtZepEBwkWipAR4WiuGKcHKy6pGpK6R3ROp+cOBwCCy1uipnhiGSL+3YZjr6 SmaWoNajWXvITn9pffUOwZSY4rPJlfrpUrTDNy+G4AovkEow0kma++mfiK3dpG/uYpXDhg== --n2Pv11Ogg/Ox8ay5-- From jis@jis.tzo.com Mon Sep 21 08:14:16 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52333A67C0 for ; Mon, 21 Sep 2009 08:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NCM9g2mwkif for ; Mon, 21 Sep 2009 08:14:16 -0700 (PDT) Received: from jis.tzo.com (JISVPN1.MIT.EDU [18.4.26.20]) by core3.amsl.com (Postfix) with ESMTP id 068FF3A63EC for ; Mon, 21 Sep 2009 08:14:16 -0700 (PDT) Received: by jis.tzo.com (Postfix, from userid 435) id 9826E34DAD; Mon, 21 Sep 2009 11:15:17 -0400 (EDT) Date: Mon, 21 Sep 2009 11:15:17 -0400 From: "Jeffrey I. Schiller" To: Sandra Murphy Message-ID: <20090921151517.GE10601@mit.edu> References: <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <46649EB3-A2C1-438B-91CA-CAF17130C1A8@virtualized.org> <20090920162216.GB11512@mit.edu> <20090921150201.GD10601@mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="2hMgfIw2X+zgXrFs" Content-Disposition: inline In-Reply-To: <20090921150201.GD10601@mit.edu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 15:14:16 -0000 --2hMgfIw2X+zgXrFs Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just to clarify. On Mon, Sep 21, 2009 at 10:41:58AM -0400, Sandra Murphy wrote: > We decided way back that the authorization to originate a route to a > prefix must come from the prefix holder. I agree. > And that identification of a prefix holder comes from the entity > that allocated the prefix. I agree, however I believe it is important that the =E2=80=9Centity that allocated the prefix=E2=80=9D should not be in a position to unilaterally m= ake the prefix unroutable by the prefix holder after the allocation is complete. -Jeff -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --2hMgfIw2X+zgXrFs Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIoAYJKoZIhvcNAQcCoIIIkTCCCI0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BhcwggLQMIICOaADAgECAhA7rjDxaPCv6xqNpf+C9MOcMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA1MTQxMzI3 MjZaFw0xMDA1MTQxMzI3MjZaMD0xHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx GjAYBgkqhkiG9w0BCQEWC2ppc0BtaXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA9IJotg2DKDd6bFs3F1Tlz0bolVWtqVlss7UZCyjh2b2Gbuge/Qe2sUexvauzMnu9 CvbM8BV3Msgu+F3NacfdG5iu0p0BHpUjdiyQ4MG8OmBuuvJ+UABqKP3oGRt/yzOilEHJyMzu rS3etIOjjr3IVGNMRzapoxXdBSdFUdFXUGWeAfi+hE5FPR+q3Tq1bgd/HjTvpJTc1emPQ5C8 v3pPD23gsAn1vMwSG9bxAPoEmp7YWmsVGpt4Bs2xQtKE1Gph5/znaDhl+S7Ipx3PZ09ZvfbI NRFImahDHwu0duRiPZPeaCMa3hI+hF6DDg7U7zU8l9sVW2QSifcqce6e08L7PwIDAQABoygw JjAWBgNVHREEDzANgQtqaXNAbWl0LmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAKuMzXB+BF3P7v6+4PvYS8V+9Kh19gWXyHSxvt0UX5LBub53kVmATU1CcJyd59jovoOj CHubIgWLGPmXQ2H0FJhwvM6/KyNuzpgUGfaPrVVb+/w4RFWMuVrxZuqqipNl6eT6/Smzx9kd cLVtTNkbVkWB7/aW2cyMqouhe6JNGa0OMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAlEw ggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA7rjDxaPCv6xqNpf+C9MOcMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTIxMTUxNTE3WjAjBgkqhkiG9w0BCQQxFgQUW8NL rReRtYAq2UPVvcv1so7t+7kwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEggEApHfbEWoxXp9K7WZbwJKPSRXw8leECm+EoiZ2WDANiW47IZ7yIy67//8D iFVR6678zDAUbp/63Baj7qqXxntpURV5jL8YW/GCPnjlrJPKm8DPzdcIgPe8UpcAF2ylx1S6 57Tm+t7YPpRLRy/dqlPhDqoUpsHpD27l3TPmSVnMi6/vlxcYQD3Z9Prptw/JT7nNt0+g6Ar3 rpl/9kWY6xtOKgKjjzY1AN0Zo/hqRkY/LWXgE9iD03q4+WFcEC/0tvZdSbYcj9uRP7rGQiFf 6PXrGQrdbCjWdfo9SiipSIqtVgCllI0KMbLB6o7DbSpXsGIW55vjEi9+LIGw4ioAJpSTZg== --2hMgfIw2X+zgXrFs-- From rv@kronos.NIC.DTAG.DE Mon Sep 21 09:37:54 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3BD3A6AD2 for ; Mon, 21 Sep 2009 09:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34DrqKhDXBR7 for ; Mon, 21 Sep 2009 09:37:53 -0700 (PDT) Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by core3.amsl.com (Postfix) with ESMTP id 8EB903A6AC4 for ; Mon, 21 Sep 2009 09:37:52 -0700 (PDT) Received: from kronos.NIC.DTAG.DE (kronos.NIC.DTAG.DE [194.25.1.92]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id SAA01144; Mon, 21 Sep 2009 18:38:52 +0200 (MET DST) Received: from x37.NIC.DTAG.DE (x37.NIC.DTAG.DE [194.25.1.186]) by kronos.NIC.DTAG.DE (8.8.5/8.7.1) with ESMTP id SAA18185; Mon, 21 Sep 2009 18:38:50 +0200 (MET DST) To: "Jeffrey I. Schiller" From: "Ruediger Volk, Deutsche Telekom T-Com - TE141-P1" In-Reply-To: Your message of "Mon, 21 Sep 2009 11:15:17 EDT." <20090921151517.GE10601@mit.edu> Date: Mon, 21 Sep 2009 18:38:50 +0200 Message-ID: <13525.1253551130@x37.NIC.DTAG.DE> Sender: rv@kronos.NIC.DTAG.DE Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 17:24:06 -0000 Hi Jeff, you are right that concerns for securing the allocation data and the operational use of routing authorization are different - even when the routing authorization has to build on the allocation data (hierarchy). The concerns for operational use of routing authorization need more attention. you wrote: > Just to clarify. > > On Mon, Sep 21, 2009 at 10:41:58AM -0400, Sandra Murphy wrote: > > We decided way back that the authorization to originate a route to a > > prefix must come from the prefix holder. > > I agree. > > > And that identification of a prefix holder comes from the entity > > that allocated the prefix. > > I agree, however I believe it is important that the "entity that > allocated the prefix" should not be in a position to unilaterally make > the prefix unroutable by the prefix holder after the allocation is > complete. yes, this seems to be a crucial concern of operators. So far I see two factors to deal with it: (1) agree on policies for operating the RPKI that only allows revocation (2) muck with the revocation mechanism/implementation I think both factors should be used: (1) to make explicit the intended rules and have them implemented most of the time and (2) as a safety belt against "errors" and interference from whatever parties... I guess (2) means that some non standard variation of PKI needs to be invented; how painful is that going to be for PKI folks? Other question: Operators see "uncontrolled" revocation of the authorization chain as a threat to using the RPKI to control routing. Are there other relevant threats? So far I found only "revocation" and "unexpected expiration"; where "unexpected expiration" should be dealt with by avoiding short expiration times and processes for advance expiration checking and reminders (without mucking around with the protocol). Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering From weiler@watson.org Mon Sep 21 11:00:14 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A5B28C202 for ; Mon, 21 Sep 2009 11:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUG-ye-c7DfN for ; Mon, 21 Sep 2009 11:00:13 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 48EE128C21C for ; Mon, 21 Sep 2009 11:00:13 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n8LI1ETL080661; Mon, 21 Sep 2009 14:01:14 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n8LI1EVc080656; Mon, 21 Sep 2009 14:01:14 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 21 Sep 2009 14:01:14 -0400 (EDT) From: Samuel Weiler To: "Jeffrey I. Schiller" In-Reply-To: <20090920162216.GB11512@mit.edu> Message-ID: References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <46649EB3-A2C1-438B-91CA-CAF17130C1A8@virtualized.org> <20090920162216.GB11512@mit.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Mon, 21 Sep 2009 14:01:14 -0400 (EDT) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:00:14 -0000 On Sun, 20 Sep 2009, Jeffrey I. Schiller wrote: > ... Judging from the conversations I have seen, I suspect we don?t > have a system that doesn?t effect the balance of power. > > In my opinion, it is a good idea to work on not changing the balance > of power. That may require that the allocation agencies *not* be part > of the key hierarchy. Jeff, I think this WG (and others) have been proceeding with the idea of having the RIRs in the key heirarchy because it's logically simpler: the key heirarchy would map the business relationships present in the allocation heirarchy. Trying to not upset the balance of power, while a great idea, might require mapping the current power structure and possibly establishing some more interactive relationships between the participants in it. Do you have any good ideas of where to start? -- Sam From weiler@watson.org Mon Sep 21 11:02:45 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301243A6995 for ; Mon, 21 Sep 2009 11:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKe1dSuY7K36 for ; Mon, 21 Sep 2009 11:02:44 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 3369E3A68F6 for ; Mon, 21 Sep 2009 11:02:44 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n8LI3jZi081427; Mon, 21 Sep 2009 14:03:45 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n8LI3jDl081424; Mon, 21 Sep 2009 14:03:45 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 21 Sep 2009 14:03:45 -0400 (EDT) From: Samuel Weiler To: Sandra Murphy In-Reply-To: Message-ID: References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Mon, 21 Sep 2009 14:03:45 -0400 (EDT) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:02:45 -0000 On Thu, 17 Sep 2009, Sandra Murphy wrote: > I recognize that there is an fear that this system somehow puts ISPs > under someone's control. I would answer that there is not any more > control than is already the case. David Conrad already responded to this, pointing out the technical possibilities. I think it's also instructive to look back at the message that started this thread (also from David Conrad), which astutely observes: "... their parents, grandparents, great-grandparents, etc. in the trust hierarchy potentially could, by intent, whim, or error, instantly and completely remove their ability to send/receive Internet traffic[1]? ... [1] Note that the actual accuracy of this statement is not particularly relevant since there will be folks who will spin the capabilities of the system in this way." However the system IS used, I'm sympathetic to David's concern that the potential for control could be a barrier to deployment. Which leaves us with the question of how to design a system that is resistant to capture and control. Or perhaps, as Jeff Schiller proposed, build something that doesn't change the current balance of power. What would we need to do differently in the RPKI design to prevent capture and control? -- Sam From andrei@ripe.net Mon Sep 21 11:18:24 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74CA83A6AE2 for ; Mon, 21 Sep 2009 11:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP8--kUundNN for ; Mon, 21 Sep 2009 11:18:23 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 6B92E3A6AC0 for ; Mon, 21 Sep 2009 11:18:23 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MpnTp-0007lX-Hn; Mon, 21 Sep 2009 20:19:22 +0200 Received: from andrei-robachevskys-macbook-pro-15.local (andrei.vpn.ripe.net [193.0.21.36]) by herring.ripe.net (Postfix) with ESMTP id 6C2992F592; Mon, 21 Sep 2009 20:19:17 +0200 (CEST) Message-ID: <4AB7C3A5.7050005@ripe.net> Date: Mon, 21 Sep 2009 20:19:17 +0200 From: Andrei Robachevsky User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Samuel Weiler References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb5239b6165cb96bc0163e2e4a15475e38 Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:18:24 -0000 Samuel Weiler wrote on 21-09-2009 20:03: > On Thu, 17 Sep 2009, Sandra Murphy wrote: > >> I recognize that there is an fear that this system somehow puts ISPs >> under someone's control. I would answer that there is not any more >> control than is already the case. > > David Conrad already responded to this, pointing out the technical > possibilities. > > I think it's also instructive to look back at the message that started > this thread (also from David Conrad), which astutely observes: > > "... their parents, grandparents, great-grandparents, etc. in the trust > hierarchy potentially could, by intent, whim, or error, instantly and > completely remove their ability to send/receive Internet traffic[1]? > ... > [1] Note that the actual accuracy of this statement is not particularly > relevant since there will be folks who will spin the capabilities of the > system in this way." > > However the system IS used, I'm sympathetic to David's concern that the > potential for control could be a barrier to deployment. Which leaves us > with the question of how to design a system that is resistant to capture > and control. Or perhaps, as Jeff Schiller proposed, build something > that doesn't change the current balance of power. > > What would we need to do differently in the RPKI design to prevent > capture and control? > I think, nothing. The RPKI attests to Internet resource holdings, nothing more. The worst thing that can happen is when we cannot trust uniqueness of address allocation. To mitigate concerns regarding capture and control we need to shift decision making to the ISP level as much as possible, to their routing policy definitions. In other words, require a fallback to insecure routing, rather than dropping the RPKI-invalid announcement off altogether. > -- Sam Andrei > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From robert@ripe.net Mon Sep 21 11:40:42 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5262B3A6AF4 for ; Mon, 21 Sep 2009 11:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=-1.243, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM68O9JODlTV for ; Mon, 21 Sep 2009 11:40:41 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 2EE163A6AF1 for ; Mon, 21 Sep 2009 11:40:41 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MpnpQ-0007kR-SP for sidr@ietf.org; Mon, 21 Sep 2009 20:41:42 +0200 Received: from Kistel-Mac.local (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id CE9A22F592 for ; Mon, 21 Sep 2009 20:41:36 +0200 (CEST) Message-ID: <4AB7C8E0.9070003@ripe.net> Date: Mon, 21 Sep 2009 20:41:36 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: sidr@ietf.org References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274a9f3c854e9125de65245b8283bd30385 Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:40:42 -0000 Samuel Weiler wrote: [...] > What would we need to do differently in the RPKI design to prevent > capture and control? I'm sorry for pointing out the obvious, but in _any_ system where you receive a certificate from someone else -- like it or not -- that someone else will have the means of revoking your cert, or not renewing it. As simple as that. It can be an error, a bug, and (horrible dictu) abuse of power, the real cause ultimately doesn't really matter. So you either certify yourself -- which is, IMO exactly as useful as not certifying at all --, or actually trusting your parent. So maybe the appropriate question is who to trust in this scenario? Someone who actually _knows_ what resources you hold at the moment, or someone who may have some idea about it, or maybe not, but definitely would _like to be_ your parent here for a reasonable sum? The answer is pretty obvious to me. Robert From christopher.morrow@gmail.com Mon Sep 21 11:56:37 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321FA3A67E5 for ; Mon, 21 Sep 2009 11:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu-RlkcG1B7J for ; Mon, 21 Sep 2009 11:56:36 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 2819D3A680C for ; Mon, 21 Sep 2009 11:56:36 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 8so1106385qwh.31 for ; Mon, 21 Sep 2009 11:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=vjHigsGzwt2VNS3GZqEYpVmjaYvNWWNp0vcymOCQY58=; b=skVBbnWpjvaUn08xjaVTGBKIsPbt8Gu/g6Ta2K8e67cmU85WecJ1wvbAXRNLNi4W9t +y9GH5XriBZYhBc67lGSCKD6FocuzuhElKqO00lfFsT+0Os6x3pUrnvUlZMqLc65Ko87 x60MyAA+aV/8yCe9HcJ/F/h7LXRRk58mT3kRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EUS2y+vz9GsCZozIviwiauDXY+CHjb2hAdsydAJoMJ/+KKm2oTWWvbqkvoj5ofSSIJ vMoDFv/nE3k1wPBuTF/cjGZM6JMwF0rX+FLpgBm8xeAaznVcsXI3jzRJau9oYbaHq6iu q4LkQeWOnMp8+6UebmqPzTv8m4zjdH94dp18M= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.54.206 with SMTP id r14mr3791657qag.204.1253559453263; Mon, 21 Sep 2009 11:57:33 -0700 (PDT) In-Reply-To: <4AB7C3A5.7050005@ripe.net> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <4AB7C3A5.7050005@ripe.net> Date: Mon, 21 Sep 2009 14:57:30 -0400 X-Google-Sender-Auth: 8a40bfe6acdabfe2 Message-ID: <75cb24520909211157m1bb4ccb2u5f28e53d36ed5e7b@mail.gmail.com> From: Christopher Morrow To: Andrei Robachevsky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Samuel Weiler , sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:56:37 -0000 On Mon, Sep 21, 2009 at 2:19 PM, Andrei Robachevsky wrote= : > Samuel Weiler wrote on 21-09-2009 20:03: >> On Thu, 17 Sep 2009, Sandra Murphy wrote: >> >>> I recognize that there is an fear that this system somehow puts ISPs >>> under someone's control. =A0I would answer that there is not any more >>> control than is already the case. >> >> David Conrad already responded to this, pointing out the technical >> possibilities. >> >> I think it's also instructive to look back at the message that started >> this thread (also from David Conrad), which astutely observes: >> >> "... their parents, grandparents, great-grandparents, etc. in the trust >> hierarchy potentially could, by intent, whim, or error, instantly and >> completely remove their ability to send/receive Internet traffic[1]? >> ... >> [1] Note that the actual accuracy of this statement is not particularly >> relevant since there will be folks who will spin the capabilities of the >> system in this way." >> >> However the system IS used, I'm sympathetic to David's concern that the >> potential for control could be a barrier to deployment. =A0Which leaves = us >> with the question of how to design a system that is resistant to capture >> and control. =A0Or perhaps, as Jeff Schiller proposed, build something >> that doesn't change the current balance of power. >> >> What would we need to do differently in the RPKI design to prevent >> capture and control? >> > > I think, nothing. The RPKI attests to Internet resource holdings, > nothing more. The worst thing that can happen is when we cannot trust > uniqueness of address allocation. > > To mitigate concerns regarding capture and control we need to shift > decision making to the ISP level as much as possible, to their routing > policy definitions. In other words, require a fallback to insecure > routing, rather than dropping the RPKI-invalid announcement off altogethe= r. not 'require' but 'make provisions for' ... which I think is more a router-os/router-policy-engine implementation (and customers asking for this knob, akin to 'accept-own-as'). -chris > >> -- Sam > > Andrei > >> _______________________________________________ >> 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 Sandra.Murphy@cobham.com Mon Sep 21 13:38:29 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517C43A699F for ; Mon, 21 Sep 2009 13:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Kjy5GqTw+MK for ; Mon, 21 Sep 2009 13:38:28 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 7EA7D3A6900 for ; Mon, 21 Sep 2009 13:38:28 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n8LKdR6L013914; Mon, 21 Sep 2009 15:39:27 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n8LKdRNV032138; Mon, 21 Sep 2009 15:39:28 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.121]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 16:39:27 -0400 Date: Mon, 21 Sep 2009 16:39:26 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Jeffrey I. Schiller" In-Reply-To: <20090921151517.GE10601@mit.edu> Message-ID: References: <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <46649EB3-A2C1-438B-91CA-CAF17130C1A8@virtualized.org> <20090920162216.GB11512@mit.edu> <20090921150201.GD10601@mit.edu> <20090921151517.GE10601@mit.edu> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="350026730-21076-1253564936=:1564" X-OriginalArrivalTime: 21 Sep 2009 20:39:27.0832 (UTC) FILETIME=[9CFA1D80:01CA3AFB] Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 20:38:29 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --350026730-21076-1253564936=:1564 Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 21 Sep 2009, Jeffrey I. Schiller wrote: > Just to clarify. > > On Mon, Sep 21, 2009 at 10:41:58AM -0400, Sandra Murphy wrote: >> We decided way back that the authorization to originate a route to a >> prefix must come from the prefix holder. > > I agree. > >> And that identification of a prefix holder comes from the entity >> that allocated the prefix. > > I agree, however I believe it is important that the =E2=80=9Centity that > allocated the prefix=E2=80=9D should not be in a position to unilaterally= make > the prefix unroutable by the prefix holder after the allocation is > complete. I have heard many complaints from ISPs about former customers who refuse=20 to return allocated address space. For those, I believe that a way to=20 un-do an allocation and to make the prefix unroutable (at least to the=20 former customer) would be desireable. Are you implying that you don't=20 think that should be allowed? Your phrase "after the allocation is complete" seems to view address=20 allocation as a permanent transfer. That is not current reality for PA=20 space - are you advocating that it should be? --Sandy > > -Jeff > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Jeffrey I. Schiller > MIT Network Manager > Information Services and Technology > Massachusetts Institute of Technology > 77 Massachusetts Avenue Room W92-190 > Cambridge, MA 02139-4307 > 617.253.0161 - Voice > jis@mit.edu > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --350026730-21076-1253564936=:1564-- From jis@jis.tzo.com Mon Sep 21 15:25:23 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322263A695F for ; Mon, 21 Sep 2009 15:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRb39Z1TPOKv for ; Mon, 21 Sep 2009 15:25:22 -0700 (PDT) Received: from jis.tzo.com (JISVPN1.MIT.EDU [18.4.26.20]) by core3.amsl.com (Postfix) with ESMTP id 63E6B3A680F for ; Mon, 21 Sep 2009 15:25:22 -0700 (PDT) Received: by jis.tzo.com (Postfix, from userid 435) id 14A2A34DAD; Mon, 21 Sep 2009 18:26:23 -0400 (EDT) Date: Mon, 21 Sep 2009 18:26:23 -0400 From: "Jeffrey I. Schiller" To: Sandra Murphy Message-ID: <20090921222623.GB16280@mit.edu> References: <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <46649EB3-A2C1-438B-91CA-CAF17130C1A8@virtualized.org> <20090920162216.GB11512@mit.edu> <20090921150201.GD10601@mit.edu> <20090921151517.GE10601@mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="Pd0ReVV5GZGQvF3a" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:25:23 -0000 --Pd0ReVV5GZGQvF3a Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 21, 2009 at 04:39:26PM -0400, Sandra Murphy wrote: > I have heard many complaints from ISPs about former customers who refuse > to return allocated address space. For those, I believe that a way to > un-do an allocation and to make the prefix unroutable (at least to the > former customer) would be desireable. Are you implying that you don't > think that should be allowed? I don=E2=80=99t believe that RPKI should be the enforcement mechanism. > Your phrase "after the allocation is complete" seems to view address > allocation as a permanent transfer. That is not current reality for PA > space - are you advocating that it should be? I=E2=80=99ve really been thinking about non PA space. I see the appeal of R= PKI to help in cases where an organization isn=E2=80=99t returning space to an = ISP after a contract has terminated. I won=E2=80=99t go so far as to say I am advocating that all assignments should be permanent, that=E2=80=99s a matter of civil and contract law. I am saying that if RPKI is or can easily be used as an enforcement mechanism, then there will be opposition to its deployment. -Jeff -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Pd0ReVV5GZGQvF3a Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIoAYJKoZIhvcNAQcCoIIIkTCCCI0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BhcwggLQMIICOaADAgECAhA7rjDxaPCv6xqNpf+C9MOcMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA1MTQxMzI3 MjZaFw0xMDA1MTQxMzI3MjZaMD0xHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx GjAYBgkqhkiG9w0BCQEWC2ppc0BtaXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA9IJotg2DKDd6bFs3F1Tlz0bolVWtqVlss7UZCyjh2b2Gbuge/Qe2sUexvauzMnu9 CvbM8BV3Msgu+F3NacfdG5iu0p0BHpUjdiyQ4MG8OmBuuvJ+UABqKP3oGRt/yzOilEHJyMzu rS3etIOjjr3IVGNMRzapoxXdBSdFUdFXUGWeAfi+hE5FPR+q3Tq1bgd/HjTvpJTc1emPQ5C8 v3pPD23gsAn1vMwSG9bxAPoEmp7YWmsVGpt4Bs2xQtKE1Gph5/znaDhl+S7Ipx3PZ09ZvfbI NRFImahDHwu0duRiPZPeaCMa3hI+hF6DDg7U7zU8l9sVW2QSifcqce6e08L7PwIDAQABoygw JjAWBgNVHREEDzANgQtqaXNAbWl0LmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAKuMzXB+BF3P7v6+4PvYS8V+9Kh19gWXyHSxvt0UX5LBub53kVmATU1CcJyd59jovoOj CHubIgWLGPmXQ2H0FJhwvM6/KyNuzpgUGfaPrVVb+/w4RFWMuVrxZuqqipNl6eT6/Smzx9kd cLVtTNkbVkWB7/aW2cyMqouhe6JNGa0OMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAlEw ggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA7rjDxaPCv6xqNpf+C9MOcMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTIxMjIyNjIzWjAjBgkqhkiG9w0BCQQxFgQUCt7n Hk0vLQQJ1eOq/RkLAOcFfdEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEggEAEKmj7A+cshv9Sz1Vmpzw32753qk/DShVS9XXnmHoZ+B3X3wrqasL/lUa bCPwXz2nFcA0KjVvLTB2CVA76kNMXX0EuFjVYKQ+FoVFtDV/S+mInwiSr4oi4uz8w/5aSde4 9hCoCiZBBnnDf7afnAIRmHXXlsVk3iA5rzwyF1cOOhhWqc/Q0jWOetxzjzV2YebJLH/5gjF6 mdAogf+rAmB8SwH1iT9H1NRdWapYcUSUhIBHUVu2fAuf3axJNlKK5zHu0SGrRHzCDfs1h3Yv WgBAreh6kg49hjhuG0eKRh9DFdPg8ux5jl2lnytRiOVet6gRlvpVDdB+4z3IkDLXcDKnRA== --Pd0ReVV5GZGQvF3a-- From jis@jis.tzo.com Mon Sep 21 15:28:22 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B483A6945 for ; Mon, 21 Sep 2009 15:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-PKvHeGHJL5 for ; Mon, 21 Sep 2009 15:28:21 -0700 (PDT) Received: from jis.tzo.com (JISVPN1.MIT.EDU [18.4.26.20]) by core3.amsl.com (Postfix) with ESMTP id 492843A680A for ; Mon, 21 Sep 2009 15:28:21 -0700 (PDT) Received: by jis.tzo.com (Postfix, from userid 435) id 90DF334DAD; Mon, 21 Sep 2009 18:29:23 -0400 (EDT) Date: Mon, 21 Sep 2009 18:29:23 -0400 From: "Jeffrey I. Schiller" To: Robert Kisteleki Message-ID: <20090921222923.GC16280@mit.edu> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <4AB7C8E0.9070003@ripe.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="H8ygTp4AXg6deix2" Content-Disposition: inline In-Reply-To: <4AB7C8E0.9070003@ripe.net> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:28:22 -0000 --H8ygTp4AXg6deix2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 21, 2009 at 08:41:36PM +0200, Robert Kisteleki wrote: > I'm sorry for pointing out the obvious, but in _any_ system where you > receive a certificate from someone else -- like it or not -- that someone > else will have the means of revoking your cert, or not renewing it. As > simple as that. It can be an error, a bug, and (horrible dictu) abuse of > power, the real cause ultimately doesn't really matter. But in the currently deployed PKI for web certificates, you have a choice of CA=E2=80=99s. If one is abusing you (makes too many errors, etc.) you can switch to another. They are all =E2=80=9Cequal=E2=80=9D in the end = user=E2=80=99s browser (I won=E2=80=99t go into EV certs here, that is a whole different kettle of fish). I believe the competition between CA=E2=80=99s helps level the playing field between those issuing certificates and those purchasing them. -Jeff -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --H8ygTp4AXg6deix2 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIoAYJKoZIhvcNAQcCoIIIkTCCCI0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BhcwggLQMIICOaADAgECAhA7rjDxaPCv6xqNpf+C9MOcMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA1MTQxMzI3 MjZaFw0xMDA1MTQxMzI3MjZaMD0xHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx GjAYBgkqhkiG9w0BCQEWC2ppc0BtaXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA9IJotg2DKDd6bFs3F1Tlz0bolVWtqVlss7UZCyjh2b2Gbuge/Qe2sUexvauzMnu9 CvbM8BV3Msgu+F3NacfdG5iu0p0BHpUjdiyQ4MG8OmBuuvJ+UABqKP3oGRt/yzOilEHJyMzu rS3etIOjjr3IVGNMRzapoxXdBSdFUdFXUGWeAfi+hE5FPR+q3Tq1bgd/HjTvpJTc1emPQ5C8 v3pPD23gsAn1vMwSG9bxAPoEmp7YWmsVGpt4Bs2xQtKE1Gph5/znaDhl+S7Ipx3PZ09ZvfbI NRFImahDHwu0duRiPZPeaCMa3hI+hF6DDg7U7zU8l9sVW2QSifcqce6e08L7PwIDAQABoygw JjAWBgNVHREEDzANgQtqaXNAbWl0LmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAKuMzXB+BF3P7v6+4PvYS8V+9Kh19gWXyHSxvt0UX5LBub53kVmATU1CcJyd59jovoOj CHubIgWLGPmXQ2H0FJhwvM6/KyNuzpgUGfaPrVVb+/w4RFWMuVrxZuqqipNl6eT6/Smzx9kd cLVtTNkbVkWB7/aW2cyMqouhe6JNGa0OMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAlEw ggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA7rjDxaPCv6xqNpf+C9MOcMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTIxMjIyOTIzWjAjBgkqhkiG9w0BCQQxFgQUqOUi xdWOK3845Lt3IAO1hLcCL2wwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEggEA0KIPtrLF5z2fatp5A6XszctdYfyGFldY5ptCSoUb4bFVgBqc4Pk642EC S0kvN5YJov5tvx6X6JNPVkPQtjuYHfS04ir4fctfB/C/4jnBXlV9b1jgb46h4qm3IoCO0nNN KMV4r1zZcu9NqhJSEF7JwG3jT1U8CNujfJoZlCFD1hggPSASlw1d+h1PVSgjr9lOwNrB7Yao sa3xfGzyU7dQdckUJGP1ewrqX6NNbKj1yz44xKV8tbI90fd9yRZjkHvGI1SjOwovaLdU8iQf BfojfE6sW1xbbFvDX7eNsVFHoD2sQmoBskODZbpJ/KIknQplDpX28xKU2nvAlkfbZ++7gg== --H8ygTp4AXg6deix2-- From christopher.morrow@gmail.com Mon Sep 21 15:48:28 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064243A6982 for ; Mon, 21 Sep 2009 15:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wgb-COdCt40W for ; Mon, 21 Sep 2009 15:48:27 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.221.172]) by core3.amsl.com (Postfix) with ESMTP id DFADC3A68DB for ; Mon, 21 Sep 2009 15:48:26 -0700 (PDT) Received: by qyk2 with SMTP id 2so2688451qyk.21 for ; Mon, 21 Sep 2009 15:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=LoyBi4l7/xlJlaNJyQlf4HiFqJoFX7uNU4VySlckcXY=; b=P1cSJ5VRkdfy7Gj+vycXW445YmO8wc+qrnjD9kPcnp8grh5asSzm3Mq4PGQcQmK3+B yTrMqRwnUQWvSFjkzlXp25rK4W9mj+RfColSLqscl60uD8cS7hZUVQ1mbHYbWPVDpbRT lX6byqi6aO1Skfv1mHXx+9GV/L/bR/beHLpyc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=bxpfoze14jJUeShVFWlpw331L342JoTpLbHAW1+xLP275IOpaOLw9/qD7XwSqsDyvv PpQYpUUdcNe9FzXAa3dfjwEksbBqZ2A6MGr9QpSD7OjS5BjHcG5qp95GJ6Obl+vmdpjn U10SQHC24qUpNpuYtlxzLukvdNTDCSvF+Gaos= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.46.79 with SMTP id i15mr169930qaf.58.1253573366572; Mon, 21 Sep 2009 15:49:26 -0700 (PDT) In-Reply-To: <20090921222923.GC16280@mit.edu> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <4AB7C8E0.9070003@ripe.net> <20090921222923.GC16280@mit.edu> Date: Mon, 21 Sep 2009 18:49:26 -0400 X-Google-Sender-Auth: 1ceee3b6745e7ca8 Message-ID: <75cb24520909211549r2460f0afp298c4e4710f4781f@mail.gmail.com> From: Christopher Morrow To: "Jeffrey I. Schiller" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:48:28 -0000 On Mon, Sep 21, 2009 at 6:29 PM, Jeffrey I. Schiller wrote: > On Mon, Sep 21, 2009 at 08:41:36PM +0200, Robert Kisteleki wrote: >> I'm sorry for pointing out the obvious, but in _any_ system where you >> receive a certificate from someone else -- like it or not -- that someon= e >> else will have the means of revoking your cert, or not renewing it. As >> simple as that. It can be an error, a bug, and (horrible dictu) abuse of >> power, the real cause ultimately doesn't really matter. > > But in the currently deployed PKI for web certificates, you have a > choice of CA=92s. If one is abusing you (makes too many errors, etc.) > you can switch to another. They are all =93equal=94 in the end user=92s > browser (I won=92t go into EV certs here, that is a whole different > kettle of fish). sure, and as it happens you can also have more than one certificate for mozilla.com .... which is 'bad'. > I believe the competition between CA=92s helps level the playing field > between those issuing certificates and those purchasing them. I'm not sure that's the case, since I can go to startssl.com and get a cert for free that's good for 1yr and doesn't raise exceptions in +98% of the user base... or I can go to verisign get the same thing for 1k$. I'm also not sure that the web-ca world tracks at all well with the routing-ca world. Is some of the concern here legacy space being pulled under 'RSA' by hook/crook? Could that be 'fixed' by IANA issuing certs to legacy address holders as that's likely the closest thing to the NIC that exists today and doesn't REALLY have the ability to enforce RSA-like restrictions as an RIR would? -Chris From jis@jis.tzo.com Mon Sep 21 20:56:44 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64783A682E for ; Mon, 21 Sep 2009 20:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNUB+RufFjYo for ; Mon, 21 Sep 2009 20:56:43 -0700 (PDT) Received: from jis.tzo.com (JISVPN1.MIT.EDU [18.4.26.20]) by core3.amsl.com (Postfix) with ESMTP id 634A43A67FB for ; Mon, 21 Sep 2009 20:56:43 -0700 (PDT) Received: by jis.tzo.com (Postfix, from userid 435) id 7996B34DAE; Mon, 21 Sep 2009 23:57:45 -0400 (EDT) Date: Mon, 21 Sep 2009 23:57:45 -0400 From: "Jeffrey I. Schiller" To: Christopher Morrow Message-ID: <20090922035745.GC3788@mit.edu> References: <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <4AB7C8E0.9070003@ripe.net> <20090921222923.GC16280@mit.edu> <75cb24520909211549r2460f0afp298c4e4710f4781f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="Bu8it7iiRSEf40bY" Content-Disposition: inline In-Reply-To: <75cb24520909211549r2460f0afp298c4e4710f4781f@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 03:56:44 -0000 --Bu8it7iiRSEf40bY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 21, 2009 at 06:49:26PM -0400, Christopher Morrow wrote: > sure, and as it happens you can also have more than one certificate > for mozilla.com .... which is 'bad'. Exactly how is this bad? Sure for S/MIME encryption you need to know which certificate to encrypt a message for (though you could do it for all of them if the number was reasonable). However for authentication you can have many certificates with the same DN. It works just fine. I should know, I run the PKI for MIT and on the client side people have one certificate per computer in general (because getting one on each computer is easier then having them figure out how to export the certificate as a pkcs12 object and import it to the other browser). Yes, we use X.509 certificates for client authentication. > I'm not sure that's the case, since I can go to startssl.com and get a > cert for free that's good for 1yr and doesn't raise exceptions in +98% > of the user base... or I can go to verisign get the same thing for > 1k$. I'm also not sure that the web-ca world tracks at all well with > the routing-ca world. Your statement proves my point about competition. If it weren=E2=80=99t for competition you would not have the option of getting one for free, or even cheap! > Is some of the concern here legacy space being pulled under 'RSA' by > hook/crook? Could that be 'fixed' by IANA issuing certs to legacy > address holders as that's likely the closest thing to the NIC that > exists today and doesn't REALLY have the ability to enforce RSA-like > restrictions as an RIR would? Or we can just have a pseudo-RIR for the legacy space (pseudo because it doesn=E2=80=99t allocate any new space, just keeps track of the old). -Jeff -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Bu8it7iiRSEf40bY Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIoAYJKoZIhvcNAQcCoIIIkTCCCI0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BhcwggLQMIICOaADAgECAhA7rjDxaPCv6xqNpf+C9MOcMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA1MTQxMzI3 MjZaFw0xMDA1MTQxMzI3MjZaMD0xHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx GjAYBgkqhkiG9w0BCQEWC2ppc0BtaXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA9IJotg2DKDd6bFs3F1Tlz0bolVWtqVlss7UZCyjh2b2Gbuge/Qe2sUexvauzMnu9 CvbM8BV3Msgu+F3NacfdG5iu0p0BHpUjdiyQ4MG8OmBuuvJ+UABqKP3oGRt/yzOilEHJyMzu rS3etIOjjr3IVGNMRzapoxXdBSdFUdFXUGWeAfi+hE5FPR+q3Tq1bgd/HjTvpJTc1emPQ5C8 v3pPD23gsAn1vMwSG9bxAPoEmp7YWmsVGpt4Bs2xQtKE1Gph5/znaDhl+S7Ipx3PZ09ZvfbI NRFImahDHwu0duRiPZPeaCMa3hI+hF6DDg7U7zU8l9sVW2QSifcqce6e08L7PwIDAQABoygw JjAWBgNVHREEDzANgQtqaXNAbWl0LmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAKuMzXB+BF3P7v6+4PvYS8V+9Kh19gWXyHSxvt0UX5LBub53kVmATU1CcJyd59jovoOj CHubIgWLGPmXQ2H0FJhwvM6/KyNuzpgUGfaPrVVb+/w4RFWMuVrxZuqqipNl6eT6/Smzx9kd cLVtTNkbVkWB7/aW2cyMqouhe6JNGa0OMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAlEw ggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA7rjDxaPCv6xqNpf+C9MOcMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTIyMDM1NzQ1WjAjBgkqhkiG9w0BCQQxFgQU3Wqh dE0RvjYnlb0PQIeGVDvDmiswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEggEApXlIkTyoO4s69CMclOd4J13A7Dq7/OPE5fj3R73gS7G6LtT+8+jTuhn2 hOorByffQDenWup5tYlM2kCS0RjODyyccXZb+RHIvPk9sbQdQel2Otpmktjf4+JvP0WQqVXc XyLX2Rhga9GfHLqrFMpdLGHoHHyHVNGciYV5zndmVrgT5G8LmilieTEE9iv632KgRHFl6JGR 378f+dQpjU30kFj6o2aKcpHjd4ixXKimF3/aYhDXUn048gfD0blxFX+301sfDXEzVLT79ewo 9ORON6wnXdWTUBeMqX4NZQAvsQL8NvRcNDOgof476f3V4bbJtMVGsZYrCw3J40w4sht18w== --Bu8it7iiRSEf40bY-- From curtis@occnc.com Mon Sep 21 21:08:49 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8163A6841 for ; Mon, 21 Sep 2009 21:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RnTMcH4rHr4 for ; Mon, 21 Sep 2009 21:08:49 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id CC82E3A68EB for ; Mon, 21 Sep 2009 21:08:48 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id n8M49ojL004499; Tue, 22 Sep 2009 00:09:50 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <200909220409.n8M49ojL004499@harbor.orleans.occnc.com> To: "Jeffrey I. Schiller" From: Curtis Villamizar In-reply-to: Your message of "Sun, 20 Sep 2009 12:22:16 EDT." <20090920162216.GB11512@mit.edu> Date: Tue, 22 Sep 2009 00:09:50 -0400 Sender: curtis@occnc.com Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 04:08:50 -0000 In message <20090920162216.GB11512@mit.edu> "Jeffrey I. Schiller" writes: > > In my opinion, it is a good idea to work on not changing the balance > of power. That may require that the allocation agencies *not* be part > of the key hierarchy. > > -Jeff Hi Jeff, Nice to hear from you. Interesting idea. But if this is a free for all, I can just declare to the world that I have rights to 18/8? Or maybe just the subnet that includes ns.mit.edu. And then I announce it and everyone believes it. I think that is the problem we are trying to solve. Without some form of authoritative hierarchy we haven't solved anything. One possibility is that providers can pick who they trust. If a RIR causes trouble maybe they get dropped by some providers with an alternate considered authoritative. This could make peer pressure a factor, or it could fragment the web of trust and limit acceptance. Curtis From christopher.morrow@gmail.com Mon Sep 21 22:01:45 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9D93A6783 for ; Mon, 21 Sep 2009 22:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A8iSfdtVrNr for ; Mon, 21 Sep 2009 22:01:44 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id ABDBA3A67AA for ; Mon, 21 Sep 2009 22:01:43 -0700 (PDT) Received: by ewy28 with SMTP id 28so864913ewy.42 for ; Mon, 21 Sep 2009 22:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=jS42Y+pj/B3wbmwIOUlBfn3iw8DVSR65hrnVVPfIG/U=; b=YIhGJQtBEa8ttkHZY9IHxAc6eX8cmPrTS6blek9cY6YhEiVmwA6MZBSqvUngiHWNjg 3+cFCwMXqKa0HBePUS9OcAlGdvfnuh/6cwm1eytNQCHdXYspT2DQHXATX11TA+9Qdko7 olDhPR5eS5rhJ0d9J/BV2Mhrni6LB1JiMPmxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=x6W7JbjD9i7riYcbkNJ2V8t45NVSgtNIAmLfgwOgKbBcY3Gr15iQlxgAS6m/DA6qNW 0/PJa7XUgInZtxj3FBCgjXAatJCr7IqzM4OuGkGRyi+eV40m1p2LfiJDFK1T/XUKx8eF WqIaKiDzxLKf/XtczEyQD+kAlGfZcY/4zjmow= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.211.158.8 with SMTP id k8mr484600ebo.38.1253595760884; Mon, 21 Sep 2009 22:02:40 -0700 (PDT) In-Reply-To: <20090922035745.GC3788@mit.edu> References: <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <4AB7C8E0.9070003@ripe.net> <20090921222923.GC16280@mit.edu> <75cb24520909211549r2460f0afp298c4e4710f4781f@mail.gmail.com> <20090922035745.GC3788@mit.edu> Date: Tue, 22 Sep 2009 01:02:40 -0400 X-Google-Sender-Auth: b33a4a826d471c2b Message-ID: <75cb24520909212202p6df341ffsc10386ff90eed568@mail.gmail.com> From: Christopher Morrow To: "Jeffrey I. Schiller" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 05:01:45 -0000 On Mon, Sep 21, 2009 at 11:57 PM, Jeffrey I. Schiller wrote: > On Mon, Sep 21, 2009 at 06:49:26PM -0400, Christopher Morrow wrote: >> sure, and as it happens you can also have more than one certificate >> for mozilla.com .... which is 'bad'. > > Exactly how is this bad? Sure for S/MIME encryption you need to know which www.mozilla.com did you visit? (substitute microsoft.com for updates or bank-of-boston.com for banks..) Yes, there should be more/better authentication from server to client (and vice versa) but today as a client you don't know... anyway this isn't super helpful in the route-object world, I don't think. > which certificate to encrypt a message for (though you could do it for > all of them if the number was reasonable). However for authentication > you can have many certificates with the same DN. It works just fine. I > should know, I run the PKI for MIT and on the client side people have > one certificate per computer in general (because getting one on each > computer is easier then having them figure out how to export the > certificate as a pkcs12 object and import it to the other > browser). Yes, we use X.509 certificates for client authentication. hurray :) >> I'm not sure that's the case, since I can go to startssl.com and get a >> cert for free that's good for 1yr and doesn't raise exceptions in +98% >> of the user base... or I can go to verisign get the same thing for >> 1k$. I'm also not sure that the web-ca world tracks at all well with >> the routing-ca world. > > Your statement proves my point about competition. If it weren=92t for > competition you would not have the option of getting one for free, or > even cheap! yes, example-fail :( sorry about that. I'm still not sure that the DNS world makes a good example for routing. >> Is some of the concern here legacy space being pulled under 'RSA' by >> hook/crook? Could that be 'fixed' by IANA issuing certs to legacy >> address holders as that's likely the closest thing to the NIC that >> exists today and doesn't REALLY have the ability to enforce RSA-like >> restrictions as an RIR would? > > Or we can just have a pseudo-RIR for the legacy space (pseudo because > it doesn=92t allocate any new space, just keeps track of the old). Sure, IANA was a simple guess on my part, a pseudo-RIR seems fine to me. Was the legacy space holder problem the only problem you had with the RPKI as it's been discussed? (and a psuedo-RIR would satisfy your concerns I think, right?) -Chris > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-Jeff > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Jeffrey I. Schiller > MIT Network Manager > Information Services and Technology > Massachusetts Institute of Technology > 77 Massachusetts Avenue =A0Room W92-190 > Cambridge, MA 02139-4307 > 617.253.0161 - Voice > jis@mit.edu > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > From robert@ripe.net Tue Sep 22 00:27:27 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6033A683D for ; Tue, 22 Sep 2009 00:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[AWL=3.709, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7WhEGNKLFMt for ; Tue, 22 Sep 2009 00:27:26 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id BCF413A6930 for ; Tue, 22 Sep 2009 00:27:26 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MpznT-0002wm-1N; Tue, 22 Sep 2009 09:28:28 +0200 Received: from Kistel-Mac.local (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 050712F583; Tue, 22 Sep 2009 09:28:23 +0200 (CEST) Message-ID: <4AB87C96.6090707@ripe.net> Date: Tue, 22 Sep 2009 09:28:22 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Jeffrey I. Schiller" References: <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <4AB7C8E0.9070003@ripe.net> <20090921222923.GC16280@mit.edu> <75cb24520909211549r2460f0afp298c4e4710f4781f@mail.gmail.com> <20090922035745.GC3788@mit.edu> In-Reply-To: <20090922035745.GC3788@mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a27416cfe798b29f549534aebad18b6ba2e4 Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 07:27:27 -0000 Jeffrey I. Schiller wrote: > Exactly how is this bad? Sure for S/MIME encryption you need to know > which certificate to encrypt a message for (though you could do it for > all of them if the number was reasonable). However for authentication > you can have many certificates with the same DN. It works just fine. I > should know, I run the PKI for MIT and on the client side people have > one certificate per computer in general (because getting one on each > computer is easier then having them figure out how to export the > certificate as a pkcs12 object and import it to the other > browser). Yes, we use X.509 certificates for client authentication. Jeff, tell us, can your users in MIT choose another CA for client authentication inside MIT? Can they choose the same DN with all of them (as you stated above, it "works just fine")? Robert From jis@jis.tzo.com Tue Sep 22 07:40:23 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD2E3A6A59 for ; Tue, 22 Sep 2009 07:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.004 X-Spam-Level: *** X-Spam-Status: No, score=3.004 tagged_above=-999 required=5 tests=[AWL=-4.338, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, SARE_SPOOF_COM2COM=2.536, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272, SPOOF_COM2OTH=2.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DFxzzYYdDuQ for ; Tue, 22 Sep 2009 07:40:22 -0700 (PDT) Received: from jis.tzo.com (JISVPN1.MIT.EDU [18.4.26.20]) by core3.amsl.com (Postfix) with ESMTP id 999C83A6A15 for ; Tue, 22 Sep 2009 07:40:21 -0700 (PDT) Received: by jis.tzo.com (Postfix, from userid 435) id E05B934DAE; Tue, 22 Sep 2009 10:41:22 -0400 (EDT) Date: Tue, 22 Sep 2009 10:41:22 -0400 From: "Jeffrey I. Schiller" To: Christopher Morrow Message-ID: <20090922144122.GD12950@mit.edu> References: <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <4AB7C8E0.9070003@ripe.net> <20090921222923.GC16280@mit.edu> <75cb24520909211549r2460f0afp298c4e4710f4781f@mail.gmail.com> <20090922035745.GC3788@mit.edu> <75cb24520909212202p6df341ffsc10386ff90eed568@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="f+W+jCU1fRNres8c" Content-Disposition: inline In-Reply-To: <75cb24520909212202p6df341ffsc10386ff90eed568@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 14:40:23 -0000 --f+W+jCU1fRNres8c Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 22, 2009 at 01:02:40AM -0400, Christopher Morrow wrote: > which www.mozilla.com did you visit? (substitute microsoft.com for > updates or bank-of-boston.com for banks..) It doesn=E2=80=99t matter as long as they are all really mozilla.com. If www.mozilla.com is a server farm behind a load balancer with each instance having a different certificate with the same DN, does it matter. Indeed having someone who is *not* mozilla.com have a certificate that claims it is, is a problem! [Note: It would be interesting to test my example above and see what the browsers do, given its a =E2=80=9Ccorner=E2=80=9D case we don=E2=80=99t= see in the real internet, there may well be bugs, but that is besides the point] What I can assert is that we have people with client side X.509 certificates (different ones, for different computers with different keys) go to the same website all the time without problem... and have for 12+ years! > Yes, there should be more/better authentication from server to client > (and vice versa) but today as a client you don't know... anyway this > isn't super helpful in the route-object world, I don't think. Actually as a client you *do* know. The problem with *knowing* which website you are going to isn=E2=80=99t one of certificate hierarchy issues. The problem has to do with fooling the ignorant user into thinking that paypal.com.broken.into.domain.com is really PayPal etc. Hopefully RPKI won=E2=80=99t have these problems because we are dealing with route ranges and AS numbers which are interpreted by code, no humans. > Sure, IANA was a simple guess on my part, a pseudo-RIR seems fine to > me. Was the legacy space holder problem the only problem you had with > the RPKI as it's been discussed? (and a psuedo-RIR would satisfy your > concerns I think, right?) This is an important case, but not the only one. For example today what happens if a route registry decides to raise its price by a factor of 1,000. People will turn on it (and they know this). But what happens when they raise the rate by a factor of 1,000 just for some customers (who they perceive as having deep pockets) and use RPKI to enforce this mandate. Sure, you can go to court.... and the legal process will grind... while you are not routed. Now this is a contrived example, so please don=E2=80=99t start criticizing it. The point = is that when you change the balance of power between parties you open the door for various forms of abuse. -Jeff -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --f+W+jCU1fRNres8c Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIoAYJKoZIhvcNAQcCoIIIkTCCCI0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BhcwggLQMIICOaADAgECAhA7rjDxaPCv6xqNpf+C9MOcMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA1MTQxMzI3 MjZaFw0xMDA1MTQxMzI3MjZaMD0xHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx GjAYBgkqhkiG9w0BCQEWC2ppc0BtaXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA9IJotg2DKDd6bFs3F1Tlz0bolVWtqVlss7UZCyjh2b2Gbuge/Qe2sUexvauzMnu9 CvbM8BV3Msgu+F3NacfdG5iu0p0BHpUjdiyQ4MG8OmBuuvJ+UABqKP3oGRt/yzOilEHJyMzu rS3etIOjjr3IVGNMRzapoxXdBSdFUdFXUGWeAfi+hE5FPR+q3Tq1bgd/HjTvpJTc1emPQ5C8 v3pPD23gsAn1vMwSG9bxAPoEmp7YWmsVGpt4Bs2xQtKE1Gph5/znaDhl+S7Ipx3PZ09ZvfbI NRFImahDHwu0duRiPZPeaCMa3hI+hF6DDg7U7zU8l9sVW2QSifcqce6e08L7PwIDAQABoygw JjAWBgNVHREEDzANgQtqaXNAbWl0LmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAKuMzXB+BF3P7v6+4PvYS8V+9Kh19gWXyHSxvt0UX5LBub53kVmATU1CcJyd59jovoOj CHubIgWLGPmXQ2H0FJhwvM6/KyNuzpgUGfaPrVVb+/w4RFWMuVrxZuqqipNl6eT6/Smzx9kd cLVtTNkbVkWB7/aW2cyMqouhe6JNGa0OMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAlEw ggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA7rjDxaPCv6xqNpf+C9MOcMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTIyMTQ0MTIyWjAjBgkqhkiG9w0BCQQxFgQU5BsM fKQoiEoxGiVOpGTRziv4jtQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEggEAqfvaMQVINyhSnOTrR/4fKDU97L2t2Wz14qkGvDYatA3T3rAC/0sy3lu4 C3UfHNh7fweKP1H6+zGuGidf8BFl2H+IVGHaXeFSt2MH6zKhW6d9LT85oGCRX/o9NnbKAcV7 2Lhi/6II8hG5l8r1c/Wgl8tbBE0ZYYdKrIiGl+aGjKaq6JZQ4Ach5joEK4/ktAAQ2B6e1/Rs xNPx/kqKa8qw/2VTr0mSAe8catsBpmOnpKuE4xo+foCWmPdGjxluF81V5UyJ9BsafDKWVgDH 6BQ9QFCxQrrv8aPZlB3o34BnikeqbDCGecKBW5cTYFGXuSQBz0C5NdJbbyuIpHJHbubWww== --f+W+jCU1fRNres8c-- From jis@jis.tzo.com Tue Sep 22 07:44:52 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42873A6A10 for ; Tue, 22 Sep 2009 07:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.07 X-Spam-Level: X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFThHqJGlI55 for ; Tue, 22 Sep 2009 07:44:52 -0700 (PDT) Received: from jis.tzo.com (JISVPN1.MIT.EDU [18.4.26.20]) by core3.amsl.com (Postfix) with ESMTP id F051D3A6A00 for ; Tue, 22 Sep 2009 07:44:51 -0700 (PDT) Received: by jis.tzo.com (Postfix, from userid 435) id C539434DAE; Tue, 22 Sep 2009 10:45:55 -0400 (EDT) Date: Tue, 22 Sep 2009 10:45:55 -0400 From: "Jeffrey I. Schiller" To: Robert Kisteleki Message-ID: <20090922144555.GE12950@mit.edu> References: <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <4AAEFD3A.7010606@joelhalpern.com> <4AB7C8E0.9070003@ripe.net> <20090921222923.GC16280@mit.edu> <75cb24520909211549r2460f0afp298c4e4710f4781f@mail.gmail.com> <20090922035745.GC3788@mit.edu> <4AB87C96.6090707@ripe.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="eheScQNz3K90DVRs" Content-Disposition: inline In-Reply-To: <4AB87C96.6090707@ripe.net> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 14:44:52 -0000 --eheScQNz3K90DVRs Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 22, 2009 at 09:28:22AM +0200, Robert Kisteleki wrote: > Jeff, tell us, can your users in MIT choose another CA for client > authentication inside MIT? Can they choose the same DN with all of > them (as you stated above, it "works just fine")? Yes, and we have at least one department that runs their own CA, so this in fact happens.... and it isn=E2=80=99t a problem for us. It doesn=E2=80=99t even matter if someone uses the same DN in a different CA because we only trust a CA if it issues a DN to the correct person. So it doesn=E2=80=99t matter to use if a departmental CA uses the same DN for a person as we do... as long as it is the same person! However, to be honest, our central IT services require a certificate issued by us. Not because of technical issues but because of trust issues. I can tell some interesting stories related to this, however it would be a bit off-topic for this group. -Jeff -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --eheScQNz3K90DVRs Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIoAYJKoZIhvcNAQcCoIIIkTCCCI0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BhcwggLQMIICOaADAgECAhA7rjDxaPCv6xqNpf+C9MOcMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA1MTQxMzI3 MjZaFw0xMDA1MTQxMzI3MjZaMD0xHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx GjAYBgkqhkiG9w0BCQEWC2ppc0BtaXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA9IJotg2DKDd6bFs3F1Tlz0bolVWtqVlss7UZCyjh2b2Gbuge/Qe2sUexvauzMnu9 CvbM8BV3Msgu+F3NacfdG5iu0p0BHpUjdiyQ4MG8OmBuuvJ+UABqKP3oGRt/yzOilEHJyMzu rS3etIOjjr3IVGNMRzapoxXdBSdFUdFXUGWeAfi+hE5FPR+q3Tq1bgd/HjTvpJTc1emPQ5C8 v3pPD23gsAn1vMwSG9bxAPoEmp7YWmsVGpt4Bs2xQtKE1Gph5/znaDhl+S7Ipx3PZ09ZvfbI NRFImahDHwu0duRiPZPeaCMa3hI+hF6DDg7U7zU8l9sVW2QSifcqce6e08L7PwIDAQABoygw JjAWBgNVHREEDzANgQtqaXNAbWl0LmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAKuMzXB+BF3P7v6+4PvYS8V+9Kh19gWXyHSxvt0UX5LBub53kVmATU1CcJyd59jovoOj CHubIgWLGPmXQ2H0FJhwvM6/KyNuzpgUGfaPrVVb+/w4RFWMuVrxZuqqipNl6eT6/Smzx9kd cLVtTNkbVkWB7/aW2cyMqouhe6JNGa0OMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAlEw ggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA7rjDxaPCv6xqNpf+C9MOcMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTIyMTQ0NTU1WjAjBgkqhkiG9w0BCQQxFgQUXirn wLbfrSOfDNjPbQoTYXPj+XswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEggEA4yAU/lsvFRLk85EyVnKBQpKGfTSHW3eWiivmG9gTGZ7jNPrat5nGKKRt Wze2ctZ4e29jQrmmeC+V+Ukil8xneIsoLLsdgpCm7Avbe8irs/Ci5UBtovAmLPKD+wLltSSI RKMvdR2re9DPoBNwKPAeQx3gI2a9jLTMl4wHUCBNlyhcxnn3/IKbLbGwBN8+NAu2g7RsHoes MyORvbEKtvECYmX0U7xgG4vmusDV4droe2YoCtwvX4uzIcs4Wg4u0vN0b8v6+WdtKtZ7YKoD bxO5wCqK54ZbPuQ/iGl7F9pkpD0qaeMwPyKwZtg+1bQm5Mmdzsbhqf4XrHJ/f1nJjXdIJQ== --eheScQNz3K90DVRs-- From jis@jis.tzo.com Tue Sep 22 07:52:01 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7354F3A6A5A for ; Tue, 22 Sep 2009 07:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.192 X-Spam-Level: X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=0.854, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QETVi62GReoh for ; Tue, 22 Sep 2009 07:52:00 -0700 (PDT) Received: from jis.tzo.com (JISVPN1.MIT.EDU [18.4.26.20]) by core3.amsl.com (Postfix) with ESMTP id 056A528C115 for ; Tue, 22 Sep 2009 07:52:00 -0700 (PDT) Received: by jis.tzo.com (Postfix, from userid 435) id E0D1934DAE; Tue, 22 Sep 2009 10:53:03 -0400 (EDT) Date: Tue, 22 Sep 2009 10:53:03 -0400 From: "Jeffrey I. Schiller" To: Curtis Villamizar Message-ID: <20090922145303.GF12950@mit.edu> References: <20090920162216.GB11512@mit.edu> <200909220409.n8M49ojL004499@harbor.orleans.occnc.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="tMbDGjvJuJijemkf" Content-Disposition: inline In-Reply-To: <200909220409.n8M49ojL004499@harbor.orleans.occnc.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 14:52:01 -0000 --tMbDGjvJuJijemkf Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 22, 2009 at 12:09:50AM -0400, Curtis Villamizar wrote: > Interesting idea. But if this is a free for all, I can just declare > to the world that I have rights to 18/8? Or maybe just the subnet > that includes ns.mit.edu. And then I announce it and everyone > believes it. Well first you would have to convince a CA for RPKI that you are in fact the legitimate holder of 18/8. Given that the CA=E2=80=99s should check the WHOIS data for 18/8, they should see that you are not MIT and not issue the cert. Now there is always the possibility that someone will make a mistake and issue the certificate anyway. This is but one reason why revocation is important, so we can correct such mistakes when they happen. If a particular CA seems to be making many mistakes, then maybe it has its certificate revoked and we move on (better hope the trust anchors behave!). > I think that is the problem we are trying to solve. Without some form > of authoritative hierarchy we haven't solved anything. > > One possibility is that providers can pick who they trust. If a RIR > causes trouble maybe they get dropped by some providers with an > alternate considered authoritative. This could make peer pressure a > factor, or it could fragment the web of trust and limit acceptance. This is risky (and will happen). The way to avoid problem here is to have a good set of trust anchors up front, complete with multiple sources of certificates for each situation. In this fashion if one CA doesn=E2=80=99t issue a certificate, another can. At this end of the day, the more I think about this the more I am beginning to believe that it is the providers (aka ISP=E2=80=99s) who should run the CA=E2=80=99s (or an organization chartered by them). For at the end= of the day, it is the providers and their customers who are the stake holders in this game. =46rom an IETF perspective, if we want RPKI to be deployed, it is the providers that have to be sold... and selling a system that causes them to lose control (even to a small degree) of a service which is essential to their core business, will be a difficult sell. -Jeff -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --tMbDGjvJuJijemkf Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIoAYJKoZIhvcNAQcCoIIIkTCCCI0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BhcwggLQMIICOaADAgECAhA7rjDxaPCv6xqNpf+C9MOcMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA1MTQxMzI3 MjZaFw0xMDA1MTQxMzI3MjZaMD0xHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx GjAYBgkqhkiG9w0BCQEWC2ppc0BtaXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA9IJotg2DKDd6bFs3F1Tlz0bolVWtqVlss7UZCyjh2b2Gbuge/Qe2sUexvauzMnu9 CvbM8BV3Msgu+F3NacfdG5iu0p0BHpUjdiyQ4MG8OmBuuvJ+UABqKP3oGRt/yzOilEHJyMzu rS3etIOjjr3IVGNMRzapoxXdBSdFUdFXUGWeAfi+hE5FPR+q3Tq1bgd/HjTvpJTc1emPQ5C8 v3pPD23gsAn1vMwSG9bxAPoEmp7YWmsVGpt4Bs2xQtKE1Gph5/znaDhl+S7Ipx3PZ09ZvfbI NRFImahDHwu0duRiPZPeaCMa3hI+hF6DDg7U7zU8l9sVW2QSifcqce6e08L7PwIDAQABoygw JjAWBgNVHREEDzANgQtqaXNAbWl0LmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAKuMzXB+BF3P7v6+4PvYS8V+9Kh19gWXyHSxvt0UX5LBub53kVmATU1CcJyd59jovoOj CHubIgWLGPmXQ2H0FJhwvM6/KyNuzpgUGfaPrVVb+/w4RFWMuVrxZuqqipNl6eT6/Smzx9kd cLVtTNkbVkWB7/aW2cyMqouhe6JNGa0OMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAlEw ggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA7rjDxaPCv6xqNpf+C9MOcMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTIyMTQ1MzAzWjAjBgkqhkiG9w0BCQQxFgQUBj3q xIloUuAp9JVM2Sx0gN/tbDgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEggEAvpFiTdJ3TYxcJ5nn/u1lNC4c5hXH/PliWEi0UGhPfGxY0LZwOoNsG6WV Jsy7lFLrppG282ilbBY7162o87mwVceLVKQA2/AbwMx5njtWnFpfffHcD82/t+SU4sLGkHNV 7avt17mFpcEjASN6hoDIp6HCOx23g/+LlvQhcEksBO1LhQUj0onNnir8ju3i4iLugDUYkh33 p62A+HZyIFcKcE4t0iLZbmaizxPh/xge5O/NYOK/W4huquM2T5F1Ji7VWQPbMWD0VcjYF566 MUO4cbC8WeJBz55oZFY6yM5duHxJumKaLl8i2NoSxuGhGtGu3Kv71Dn8Y1v+mdJW6LUA/Q== --tMbDGjvJuJijemkf-- From Donald.Smith@qwest.com Tue Sep 22 08:26:55 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60AB328C137 for ; Tue, 22 Sep 2009 08:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLRWEMduxxFR for ; Tue, 22 Sep 2009 08:26:54 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 47D9128C12F for ; Tue, 22 Sep 2009 08:26:54 -0700 (PDT) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id n8MFRuJ7011086; Tue, 22 Sep 2009 10:27:57 -0500 (CDT) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id n8MFRoWq021058; Tue, 22 Sep 2009 10:27:51 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Tue, 22 Sep 2009 09:27:50 -0600 From: "Smith, Donald" To: "'Jeffrey I. Schiller'" , "'Curtis Villamizar'" Date: Tue, 22 Sep 2009 09:27:49 -0600 Thread-Topic: [sidr] Controlling routing (was Re: WG Chair Affiliation) Thread-Index: Aco7lGjp6Bcf1qPyQQuERjgs877x/gABEsRQ Message-ID: References: <20090920162216.GB11512@mit.edu> <200909220409.n8M49ojL004499@harbor.orleans.occnc.com> <20090922145303.GF12950@mit.edu> In-Reply-To: <20090922145303.GF12950@mit.edu> 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: "'sidr@ietf.org'" Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 15:26:55 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On=20 > Behalf Of Jeffrey I. Schiller > Sent: Tuesday, September 22, 2009 8:53 AM > To: Curtis Villamizar > Cc: sidr@ietf.org > Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) >=20 > On Tue, Sep 22, 2009 at 12:09:50AM -0400, Curtis Villamizar wrote: > > Interesting idea. But if this is a free for all, I can just declare > > to the world that I have rights to 18/8? Or maybe just the subnet > > that includes ns.mit.edu. And then I announce it and everyone > > believes it. >=20 > Well first you would have to convince a CA for RPKI that you are in > fact the legitimate holder of 18/8. Given that the CA's should check > the WHOIS data for 18/8, they should see that you are not MIT and not > issue the cert. >=20 > Now there is always the possibility that someone will make a mistake > and issue the certificate anyway. This is but one reason why > revocation is important, so we can correct such mistakes when they > happen. If a particular CA seems to be making many mistakes, then > maybe it has its certificate revoked and we move on (better hope the > trust anchors behave!). >=20 > > I think that is the problem we are trying to solve. =20 > Without some form > > of authoritative hierarchy we haven't solved anything. > > > > One possibility is that providers can pick who they trust. If a RIR > > causes trouble maybe they get dropped by some providers with an > > alternate considered authoritative. This could make peer pressure a > > factor, or it could fragment the web of trust and limit acceptance. Don't we all end up having to trust the same set of RIRs? We have to trust more then just the one we choose to sign the certs. We have to trust the set that other ISPs trust too or not accept their cert= s unless I am missing something here. >=20 > This is risky (and will happen). The way to avoid problem here is to > have a good set of trust anchors up front, complete with multiple > sources of certificates for each situation. In this fashion if one CA > doesn't issue a certificate, another can. >=20 > At this end of the day, the more I think about this the more I am > beginning to believe that it is the providers (aka ISP's) who should > run the CA's (or an organization chartered by them). For at the end of > the day, it is the providers and their customers who are the stake > holders in this game. >=20 > From an IETF perspective, if we want RPKI to be deployed, it is the > providers that have to be sold... and selling a system that causes > them to lose control (even to a small degree) of a service which is > essential to their core business, will be a difficult sell. Difficult to sell is putting it mildly. Most ISPs don't run CAs today nor do they have the infrastructure to do so. Neither will they want to turn over any aspect of routing control to a 3rd = party. >=20 > -Jeff >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Jeffrey I. Schiller > MIT Network Manager > Information Services and Technology > Massachusetts Institute of Technology > 77 Massachusetts Avenue Room W92-190 > Cambridge, MA 02139-4307 > 617.253.0161 - Voice > jis@mit.edu > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = From christopher.morrow@gmail.com Tue Sep 22 10:12:09 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9EC93A6AAC for ; Tue, 22 Sep 2009 10:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZMIv7WwbHYN for ; Tue, 22 Sep 2009 10:12:09 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id DB1C73A6A1D for ; Tue, 22 Sep 2009 10:12:08 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 8so1387119qwh.31 for ; Tue, 22 Sep 2009 10:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=+fsndedEEBnd1P7/vh1mMbT84vWcsZJSTFMUUWHhYyE=; b=B/uS7IHcJeCad8LF0JJ+mtsPMgpx3huMNVix+QqcqoFc0CC5UP4NgxhlLOpfpVto0N g3uO0sLl6xs9eFEsYh2b9jF5phQjKE6gus3hQMYvBW/0A76ECVcB015scLp2tkFQHLG1 McOR4YmpiNt/vSHj+MOl8r85/4DIGNIUN+sqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=lbVKta4TYNM3g5UlYvG703/KkMcWf4wgHbTrvbZseL2PvnBmuiqoeNQVJPYkp6EjMC kN6VjrMdwZMCB6l7Noh2vwqOtLoNtSzbWvfjiXA1kWDkPnoOiNvkT6/8ix0g8BDnTO+t m2GfM+FtNpcF2tz2FzFGygxMIk/E38okkMWEg= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.63.218 with SMTP id c26mr964680qai.92.1253639590001; Tue, 22 Sep 2009 10:13:10 -0700 (PDT) In-Reply-To: References: <20090920162216.GB11512@mit.edu> <200909220409.n8M49ojL004499@harbor.orleans.occnc.com> <20090922145303.GF12950@mit.edu> Date: Tue, 22 Sep 2009 13:13:09 -0400 X-Google-Sender-Auth: 2c21606cf08e352d Message-ID: <75cb24520909221013q11d03939n1c0a73dd0b0f05d4@mail.gmail.com> From: Christopher Morrow To: "Smith, Donald" Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 17:12:09 -0000 On Tue, Sep 22, 2009 at 11:27 AM, Smith, Donald wrote: > Difficult to sell is putting it mildly. > Most ISPs don't run CAs today nor do they have the infrastructure to do so. > Neither will they want to turn over any aspect of routing control to a 3rd party. As a small correction.. VerizonBusiness does run a CA (betrusted/baltimore-security/cybertrust)... of course, you may not want the people who cant' get your phone bill right to control your routing either :) So, back on topic, if a party NOT the RIR-set runs the CAs (or many parties not the RIRs run the CAs), let's assume that uniqueness is maintained in address information (singular copies of netblock/allocation data). Some pointers/links back to the RIR databases would have to be maintained For grins, what about RADb running this service? (or the existing set of IRR's) What sort of implications does this have for stability and cleanliness of the data? Can we be anymore assured of having up-to-date data in the CA heirarchy than we can in the current IRR databases? If we can't be assured of that, how valuable is this new regime? -chris From ryan.shea@verizonbusiness.com Tue Sep 22 10:54:30 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9303A6972 for ; Tue, 22 Sep 2009 10:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[AWL=1.665, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a56cQcQZM72O for ; Tue, 22 Sep 2009 10:54:29 -0700 (PDT) Received: from omzesmtp02a.verizonbusiness.com (omzesmtp02a.verizonbusiness.com [199.249.25.198]) by core3.amsl.com (Postfix) with ESMTP id 72A543A6946 for ; Tue, 22 Sep 2009 10:54:29 -0700 (PDT) Received: from omzismtp01.vzbi.com ([165.122.46.164]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KQD00K27WGIW700@firewall.verizonbusiness.com> for sidr@ietf.org; Tue, 22 Sep 2009 17:55:33 +0000 (GMT) Received: from omzismtp01.vzbi.com ([127.0.0.1]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KQD00M0XWGK2Y00@omzismtp01.vzbi.com> for sidr@ietf.org; Tue, 22 Sep 2009 17:55:32 +0000 (GMT) Received: from ASHSRV139.mcilink.com ([153.39.68.165]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KQD00LAZWGEY600@omzismtp01.vzbi.com> for sidr@ietf.org; Tue, 22 Sep 2009 17:55:32 +0000 (GMT) Received: from ASHSRV109.mcilink.com ([153.39.68.162]) by ASHSRV139.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 17:55:30 +0000 Received: from [153.39.134.213] ([153.39.134.213]) by ASHSRV109.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 17:55:30 +0000 From: Ryan Shea To: "Jeffrey I. Schiller" In-reply-to: <20090922145303.GF12950@mit.edu> References: <20090920162216.GB11512@mit.edu> <200909220409.n8M49ojL004499@harbor.orleans.occnc.com> <20090922145303.GF12950@mit.edu> Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-jKrTxudc+dckPDf+Ozpg" Date: Tue, 22 Sep 2009 13:55:30 -0400 Message-id: <1253642130.13325.89.camel@ryan> MIME-version: 1.0 X-Mailer: Evolution 2.26.1 X-OriginalArrivalTime: 22 Sep 2009 17:55:30.0441 (UTC) FILETIME=[DFD91F90:01CA3BAD] Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 17:54:30 -0000 --=-jKrTxudc+dckPDf+Ozpg Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > From an IETF perspective, if we want RPKI to be deployed, it is the > providers that have to be sold... and selling a system that causes > them to lose control (even to a small degree) of a service which is > essential to their core business, will be a difficult sell. To some degree as v4 address space depletion continues providers holding smaller bits of address space may view the enhancements RPKI brings as a tool in the war on prefix hijacks. =20 Although there is plenty of sense in aligning the RPKI chain of trust with the resource allocation chain, ISPs may have concerns with the RIRs being the trust anchors. The incentive structure for the RIRs is fundamentally different than that of a certificate provider like Verisign/Thawte/CyberTrust. If these trusted root CAs time and again demonstrate that they are untrustworthy they lose customers, revenue, and potentially their trusted status. What entices an RIR toward vigilance as they validate the supposedly authorized origin of a prefix? Ryan Shea Senior Engineer, Network and Info Security Verizon Business --=-jKrTxudc+dckPDf+Ozpg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkq5D5IACgkQhdWG+NnHKoyY5gCfWhpp0G99jBiz3k2Tv361Be1L tgAAniZOOyOJDBu8+q0Q1MYs12m8UV5s =Z0st -----END PGP SIGNATURE----- --=-jKrTxudc+dckPDf+Ozpg-- From jis@jis.tzo.com Tue Sep 22 20:24:45 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD0C3A683F for ; Tue, 22 Sep 2009 20:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pl8Pefn5L+vH for ; Tue, 22 Sep 2009 20:24:44 -0700 (PDT) Received: from jis.tzo.com (JISVPN1.MIT.EDU [18.4.26.20]) by core3.amsl.com (Postfix) with ESMTP id 8A3293A6805 for ; Tue, 22 Sep 2009 20:24:44 -0700 (PDT) Received: by jis.tzo.com (Postfix, from userid 435) id 6AED434DB0; Tue, 22 Sep 2009 23:25:48 -0400 (EDT) Date: Tue, 22 Sep 2009 23:25:48 -0400 From: "Jeffrey I. Schiller" To: "Smith, Donald" Message-ID: <20090923032547.GI9352@mit.edu> References: <20090920162216.GB11512@mit.edu> <200909220409.n8M49ojL004499@harbor.orleans.occnc.com> <20090922145303.GF12950@mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="IR1Y5IvQhrKgS4e6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "'sidr@ietf.org'" Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 03:24:45 -0000 --IR1Y5IvQhrKgS4e6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 22, 2009 at 09:27:49AM -0600, Smith, Donald wrote: > Don't we all end up having to trust the same set of RIRs? We have > to trust more then just the one we choose to sign the certs. We > have to trust the set that other ISPs trust too or not accept their > certs unless I am missing something here. Yep, just like the browsers which come loaded with a bunch of CA=E2=80=99s. > Difficult to sell is putting it mildly. Most ISPs don't run CAs > today nor do they have the infrastructure to do so. Neither will > they want to turn over any aspect of routing control to a 3rd party. And then there is the whole issue of how hard or easy it will be to configure routers to actually use this stuff! Keep in mind, most ISP engineers are not PKI experts (nor security experts!). -Jeff -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --IR1Y5IvQhrKgS4e6 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIoAYJKoZIhvcNAQcCoIIIkTCCCI0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BhcwggLQMIICOaADAgECAhA7rjDxaPCv6xqNpf+C9MOcMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA1MTQxMzI3 MjZaFw0xMDA1MTQxMzI3MjZaMD0xHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx GjAYBgkqhkiG9w0BCQEWC2ppc0BtaXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA9IJotg2DKDd6bFs3F1Tlz0bolVWtqVlss7UZCyjh2b2Gbuge/Qe2sUexvauzMnu9 CvbM8BV3Msgu+F3NacfdG5iu0p0BHpUjdiyQ4MG8OmBuuvJ+UABqKP3oGRt/yzOilEHJyMzu rS3etIOjjr3IVGNMRzapoxXdBSdFUdFXUGWeAfi+hE5FPR+q3Tq1bgd/HjTvpJTc1emPQ5C8 v3pPD23gsAn1vMwSG9bxAPoEmp7YWmsVGpt4Bs2xQtKE1Gph5/znaDhl+S7Ipx3PZ09ZvfbI NRFImahDHwu0duRiPZPeaCMa3hI+hF6DDg7U7zU8l9sVW2QSifcqce6e08L7PwIDAQABoygw JjAWBgNVHREEDzANgQtqaXNAbWl0LmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAKuMzXB+BF3P7v6+4PvYS8V+9Kh19gWXyHSxvt0UX5LBub53kVmATU1CcJyd59jovoOj CHubIgWLGPmXQ2H0FJhwvM6/KyNuzpgUGfaPrVVb+/w4RFWMuVrxZuqqipNl6eT6/Smzx9kd cLVtTNkbVkWB7/aW2cyMqouhe6JNGa0OMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAlEw ggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA7rjDxaPCv6xqNpf+C9MOcMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTIzMDMyNTQ3WjAjBgkqhkiG9w0BCQQxFgQUpoVM FVh2TY1oZjFyCcZhULyLQ4IwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEggEA7QnYEBWAyq6mCVNQ3tUY+ZfuYkglHNpsCgIV3s+l3D5A5LSm5pGd6LEX TcFFzqCtHEpbkqP+FZ5oFvNv1N1rJ5urygsNHbGKGu2hXBedHd9Vtv0aJFeDjFE3evzCVT9m 6rXLmbEthnaSNWQAtb5FyZ+II0uOYI27mHCw1BcYId4PKwMt43oHWMMrSakr4/GSibIJbU3I iTREph7SAp+TIg8Vf6f1/xI2Y3wfnHsaHk5bymOZ7CDZgXWNVCIx1a157QpXKbsd7ZyFyr0D xgePUghli70VeFNEFBPtZ5DkKOesech+GXtsEMgWJAQVzesLYVLzyp3dw119z669VdOt/Q== --IR1Y5IvQhrKgS4e6-- From jis@jis.tzo.com Tue Sep 22 20:28:48 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679513A68AB for ; Tue, 22 Sep 2009 20:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZaEktatXSN9 for ; Tue, 22 Sep 2009 20:28:47 -0700 (PDT) Received: from jis.tzo.com (JISVPN1.MIT.EDU [18.4.26.20]) by core3.amsl.com (Postfix) with ESMTP id 51E1B3A6805 for ; Tue, 22 Sep 2009 20:28:47 -0700 (PDT) Received: by jis.tzo.com (Postfix, from userid 435) id B297234DB0; Tue, 22 Sep 2009 23:29:51 -0400 (EDT) Date: Tue, 22 Sep 2009 23:29:51 -0400 From: "Jeffrey I. Schiller" To: Christopher Morrow Message-ID: <20090923032951.GJ9352@mit.edu> References: <20090920162216.GB11512@mit.edu> <200909220409.n8M49ojL004499@harbor.orleans.occnc.com> <20090922145303.GF12950@mit.edu> <75cb24520909221013q11d03939n1c0a73dd0b0f05d4@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="Do4IU1xF/9sod/r6" Content-Disposition: inline In-Reply-To: <75cb24520909221013q11d03939n1c0a73dd0b0f05d4@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "sidr@ietf.org" Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 03:28:48 -0000 --Do4IU1xF/9sod/r6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 22, 2009 at 01:13:09PM -0400, Christopher Morrow wrote: > For grins, what about RADb running this service? (or the existing set > of IRR's) What sort of implications does this have for stability and > cleanliness of the data? Can we be anymore assured of having > up-to-date data in the CA heirarchy than we can in the current IRR > databases? If we can't be assured of that, how valuable is this new > regime? Actually the RADb may be a very appropriate place to run a CA. Another possibility is some subset of the existing certificate providers. They understand the PKI stuff, they would have to develop the verification procedures. Btw. It isn=E2=80=99t clear to me that the data needs to be super clean to = be useful. It has to contain all the information needed for routes to work, but if it has extra crud, that isn=E2=80=99t really a problem as long= as your goal isn=E2=80=99t data purity but instead making it harder for =E2=80= =9Cbad guys=E2=80=9D to hijack blocks. -Jeff -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Do4IU1xF/9sod/r6 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIoAYJKoZIhvcNAQcCoIIIkTCCCI0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BhcwggLQMIICOaADAgECAhA7rjDxaPCv6xqNpf+C9MOcMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA1MTQxMzI3 MjZaFw0xMDA1MTQxMzI3MjZaMD0xHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx GjAYBgkqhkiG9w0BCQEWC2ppc0BtaXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA9IJotg2DKDd6bFs3F1Tlz0bolVWtqVlss7UZCyjh2b2Gbuge/Qe2sUexvauzMnu9 CvbM8BV3Msgu+F3NacfdG5iu0p0BHpUjdiyQ4MG8OmBuuvJ+UABqKP3oGRt/yzOilEHJyMzu rS3etIOjjr3IVGNMRzapoxXdBSdFUdFXUGWeAfi+hE5FPR+q3Tq1bgd/HjTvpJTc1emPQ5C8 v3pPD23gsAn1vMwSG9bxAPoEmp7YWmsVGpt4Bs2xQtKE1Gph5/znaDhl+S7Ipx3PZ09ZvfbI NRFImahDHwu0duRiPZPeaCMa3hI+hF6DDg7U7zU8l9sVW2QSifcqce6e08L7PwIDAQABoygw JjAWBgNVHREEDzANgQtqaXNAbWl0LmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAKuMzXB+BF3P7v6+4PvYS8V+9Kh19gWXyHSxvt0UX5LBub53kVmATU1CcJyd59jovoOj CHubIgWLGPmXQ2H0FJhwvM6/KyNuzpgUGfaPrVVb+/w4RFWMuVrxZuqqipNl6eT6/Smzx9kd cLVtTNkbVkWB7/aW2cyMqouhe6JNGa0OMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAlEw ggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA7rjDxaPCv6xqNpf+C9MOcMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTIzMDMyOTUxWjAjBgkqhkiG9w0BCQQxFgQUjuVZ 0WTEpVUqEtPi2sGnCal/jcMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEggEAreBvZB8Nygb9m140lMDfE/kA5AA8YOtioAvuIBVHIMvGKoEYcRwWxHoP ChpdnCnK7nQvocOWiuVC+qFIlhyX3swDTTyRI54VNmg5DrDl7QWwYlH5FuhL7aE8W5MPLzJo yPw6W4mR679LBOrZsdYMnrF7YWw2gslHJUKSIqoaQKT0KNjY4/b7VR5mZGoQxuMLQ/PyepQJ Vr5eN28yu19l8H2kbzI1OjsnwZKrUbDq0bECXOEhyFCTt1+4JhVbXCAmZ7ogUuOj2jzn0rN7 rGtuA9CBNdOZtSKwkHltxD5mjiGeVmi9R1SHe4mkmH/KVMYLFYxInvAanTDHA8pzpqK6HA== --Do4IU1xF/9sod/r6-- From andrei@ripe.net Wed Sep 23 08:47:06 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1DD3A6A7C for ; Wed, 23 Sep 2009 08:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=-3.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce1+uXl9yV+F for ; Wed, 23 Sep 2009 08:47:05 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id C1E2B3A6A31 for ; Wed, 23 Sep 2009 08:47:05 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MqU4Y-00049I-It; Wed, 23 Sep 2009 17:48:08 +0200 Received: from andrei-robachevskys-macbook-pro-15.local (andrei.vpn.ripe.net [193.0.21.36]) by herring.ripe.net (Postfix) with ESMTP id 77CC12F583; Wed, 23 Sep 2009 17:48:02 +0200 (CEST) Message-ID: <4ABA4332.6070002@ripe.net> Date: Wed, 23 Sep 2009 17:48:02 +0200 From: Andrei Robachevsky User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Ryan Shea References: <20090920162216.GB11512@mit.edu> <200909220409.n8M49ojL004499@harbor.orleans.occnc.com> <20090922145303.GF12950@mit.edu> <1253642130.13325.89.camel@ryan> In-Reply-To: <1253642130.13325.89.camel@ryan> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb88072c4f5b549be40d5cf65519cc8d10 Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 15:47:06 -0000 Ryan Shea wrote on 22-09-2009 19:55: [...] > and potentially their trusted status. What entices an RIR toward > vigilance as they validate the supposedly authorized origin of a prefix? > First of all, validation is performed by a relying party, for instance an ISP. Secondly, the RIRs do not authorise the origin of a prefix, that is done by a prefix holder. What the RIRs and LIRs and all other parties in the chain of resource allocation do is attest to the that at the time of issuance of a certificate the holder of the address space listed in the extensions demonstrated possession of the private key. These basic RPKI data can be used in other application, securing routing, for instance. > Ryan Shea > Senior Engineer, Network and Info Security > Verizon Business > Regards, Andrei > > ------------------------------------------------------------------------ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From ryan.shea@verizonbusiness.com Wed Sep 23 13:01:28 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934B03A6849 for ; Wed, 23 Sep 2009 13:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[AWL=1.577, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKjMGzMqT7KL for ; Wed, 23 Sep 2009 13:01:27 -0700 (PDT) Received: from omzesmtp01a.verizonbusiness.com (omzesmtp01a.verizonbusiness.com [199.249.25.195]) by core3.amsl.com (Postfix) with ESMTP id 992243A67FE for ; Wed, 23 Sep 2009 13:01:27 -0700 (PDT) Received: from pdcismtp01.vzbi.com ([166.40.77.67]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KQF00356X060H00@firewall.verizonbusiness.com> for sidr@ietf.org; Wed, 23 Sep 2009 20:02:31 +0000 (GMT) Received: from pdcismtp01.vzbi.com ([127.0.0.1]) by pdcismtp01.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KQF008JGX06JC00@pdcismtp01.vzbi.com> for sidr@ietf.org; Wed, 23 Sep 2009 20:02:30 +0000 (GMT) Received: from ASHSRV139.mcilink.com ([153.39.68.165]) by pdcismtp01.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KQF0084EX06NC00@pdcismtp01.vzbi.com> for sidr@ietf.org; Wed, 23 Sep 2009 20:02:30 +0000 (GMT) Received: from ASHSRV105.mcilink.com ([153.39.68.161]) by ASHSRV139.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 20:02:30 +0000 Received: from [153.39.134.213] ([153.39.134.213]) by ASHSRV105.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 20:02:29 +0000 From: Ryan Shea To: Andrei Robachevsky In-reply-to: <4ABA4332.6070002@ripe.net> References: <20090920162216.GB11512@mit.edu> <200909220409.n8M49ojL004499@harbor.orleans.occnc.com> <20090922145303.GF12950@mit.edu> <1253642130.13325.89.camel@ryan> <4ABA4332.6070002@ripe.net> Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AWRB55CK7L92evH+SX56" Date: Wed, 23 Sep 2009 20:02:29 +0000 Message-id: <1253736149.13325.495.camel@ryan> MIME-version: 1.0 X-Mailer: Evolution 2.26.1 X-OriginalArrivalTime: 23 Sep 2009 20:02:29.0934 (UTC) FILETIME=[C7D53CE0:01CA3C88] Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 20:01:28 -0000 --=-AWRB55CK7L92evH+SX56 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-09-23 at 17:48 +0200, Andrei Robachevsky wrote: > First of all, validation is performed by a relying party, for instance > an ISP. Secondly, the RIRs do not authorise the origin of a prefix, that > is done by a prefix holder. What the RIRs and LIRs and all other parties > in the chain of resource allocation do is attest to the that at the time > of issuance of a certificate the holder of the address space listed in > the extensions demonstrated possession of the private key. These basic > RPKI data can be used in other application, securing routing, for instanc= e. Perhaps I could clarify. I am speaking of validation of the information on the ROA rather than the validation of a chain of authority that ultimately validates the prefix/origin pairs. Please correct me if I am misunderstanding or confusing terms here. As a hypothetical illustration, let's say that RIPE were to issue 2.2.0.0/16 over to Verizon Business (702) and we had an RPKI in place. Let us also say for the sake of discussion that everyone agreed on RIPE as the trust anchor for 2.0.0.0/8. =20 In the world of SSL/TLS certificates our friends over at CyberTrust (for example) have an incentive to make sure I am truly associated with the verizonbusiness.com domain name in the CN field of my cert request before they their stamp of approval on my certificate request (fax, mail-from, government & employer id...). They are doing more than simply validating that I have the associated private key with the public key on the cert request. The ongoing revenue stream for CyberTrust is directly tied to its reputation. It has every reason to do their due diligence and confirm that I am tied to the resource. As a user with a root CA store I can decide whether or not to have CyberTrust's CA in my list. =20 An RIR may not have the same incentives to verify that me and my public key are truly associated with AS702 - so as an RP I need to think about how much I trust that the public key associated with a ROA that comes from this RIR. Further, as a provider I do not have the same ability to take my business elsewhere with regards to an RIR and allocated resources. As a corporation I can choose to end all associations with CyberTrust, both as a signer of our certificates and as a trusted CA much easier than cutting all ties with an RIR in a region I operate. The survival of an RIR is not as intricately tied to its vigilance as with the SSL model - that is the gist of what I am saying. -Ryan > Regards, >=20 > Andrei >=20 > >=20 > > -----------------------------------------------------------------------= - > >=20 > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr --=-AWRB55CK7L92evH+SX56 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkq6ftUACgkQhdWG+NnHKoxCCQCeNRZoZynIvzxbqwWmND+xr2sg QkIAnRXfKsrsDTdaXsDu7mopZgarBXa9 =oXIA -----END PGP SIGNATURE----- --=-AWRB55CK7L92evH+SX56-- From robert@ripe.net Wed Sep 23 14:13:53 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBC843A6995 for ; Wed, 23 Sep 2009 14:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[AWL=3.179, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w78HEfldwsDr for ; Wed, 23 Sep 2009 14:13:53 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id DC9DB3A68C1 for ; Wed, 23 Sep 2009 14:13:52 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MqZAo-0004st-Cs; Wed, 23 Sep 2009 23:14:55 +0200 Received: from Kistel-Mac.local (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 51F992F59E; Wed, 23 Sep 2009 23:14:50 +0200 (CEST) Message-ID: <4ABA8FCA.1020902@ripe.net> Date: Wed, 23 Sep 2009 23:14:50 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Ryan Shea References: <20090920162216.GB11512@mit.edu> <200909220409.n8M49ojL004499@harbor.orleans.occnc.com> <20090922145303.GF12950@mit.edu> <1253642130.13325.89.camel@ryan> <4ABA4332.6070002@ripe.net> <1253736149.13325.495.camel@ryan> In-Reply-To: <1253736149.13325.495.camel@ryan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2741320f508a699548b47dbedd3e99a07e5 Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 21:13:54 -0000 Ryan Shea wrote: > An RIR may not have the same incentives to verify that me and my public > key are truly associated with AS702 - so as an RP I need to think about > how much I trust that the public key associated with a ROA that comes > from this RIR. Further, as a provider I do not have the same ability to > take my business elsewhere with regards to an RIR and allocated > resources. As a corporation I can choose to end all associations with > CyberTrust, both as a signer of our certificates and as a trusted CA > much easier than cutting all ties with an RIR in a region I operate. > The survival of an RIR is not as intricately tied to its vigilance as > with the SSL model - that is the gist of what I am saying. Ryan, You are stating that only an RIR can certify a resource (which is allocated through that RIR). This is not true. On the contrary, _anyone_ can certify your resources. The question is, who will the third parties (ie. not you and not the certifier(s)!) trust -- the entity whose business is to _know_ who has those resources, or someone else? As Steve have already explained numerous times, anyone can nominate themselves to be a Trust Anchor for RPKI (or any other PKI), but that's just a self-proclamation. Again, third parties (people who will verify stuff) will choose TAs, based on who they trust. So you're absolutely free to go talk to for example Bert, and ask him to certify your allocation. He actually might, as he's a respected pers^H^H^H^H individual, everyone knows him, and he has been signing the DNS root for years, so he also has a good track record. I for one would trust the guys whose business is to manage resources, to certify those resources (no offense, Bert :-) Robert