From sharon.goldbe@gmail.com Mon Apr 1 09:18:28 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0717D1F0D07 for ; Mon, 1 Apr 2013 09:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfJfnRkwV7G6 for ; Mon, 1 Apr 2013 09:18:26 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3061F0C74 for ; Mon, 1 Apr 2013 09:18:26 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id r3so1845621wey.31 for ; Mon, 01 Apr 2013 09:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=JHNFQCwhC7bCDb1qTxsx6f8jqjUCq734qiIC7XddrsI=; b=zBFQRLTEPoeQXrudgvN308XzLx+Vsfi2tHopwZP7zgn4UMY7WKigj8lI+LkG8fQGDB IdikryY0VAj8OaGFexAV0xjy/3mpcvYzIyFPbv471y7BeFjSlEwu4tpDTA0TtQn8J2xt rYWGANIboFd3J6KDKhhe3RLGuOyaRvhu1A4JSZP99c0q0I8bje9dIVyVetimXcpy+/7/ 8KWDkeuSBg23m3hKfbQzmaysxzfJlYXDMEax+bDkfIqkVSF1gqvQDbVvLsZQN0TWag+O Moj8fGAsZL257VFwhTycFche/E84QBju/sbUAnBi8aW0oyM/AZaP2F6PTmEITcSa13uw vDJw== X-Received: by 10.194.171.74 with SMTP id as10mr16517301wjc.0.1364833105499; Mon, 01 Apr 2013 09:18:25 -0700 (PDT) MIME-Version: 1.0 Sender: sharon.goldbe@gmail.com Received: by 10.194.59.135 with HTTP; Mon, 1 Apr 2013 09:17:45 -0700 (PDT) In-Reply-To: <51506B10.6050600@bbn.com> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> From: Sharon Goldberg Date: Mon, 1 Apr 2013 12:17:45 -0400 X-Google-Sender-Auth: GAqfuQCW_GL0t3UpP0mqMH1eRwk Message-ID: To: Stephen Kent Content-Type: multipart/alternative; boundary=089e013c6c0e6e5cd904d94ef8fe Cc: dannyc@bu.edu, broglek@bu.edu, eth3rs@gmail.com, sidr@ietf.org Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:18:28 -0000 --089e013c6c0e6e5cd904d94ef8fe Content-Type: text/plain; charset=ISO-8859-1 Steve, Thanks for your careful reading of our report. We have some questions for you inline: >> -- We show that it is possible to revoke a ROA surreptitiously, >> through methods other than (the obvious) revocation lists. See Section >> 2.2.1 of the report. > > The terminology above is not quite correct, since only one of the five > "methods" results in revocation per se. I suggest using the technical > term "whacking" instead. (You're a Princeton grad, so a NJ-inspired term > of this sort seems appropriate :-) Yes, exactly. We should change all our reports to say "whacked" :) > Nonetheless, all of the methods for whacking a ROA described in the paper > are detectable by anyone who monitors the RPKI. One might argue that each > resource holder should monitor his/her RPKI pub point to detect any action > that causes one's ROA to become unverifiable. We agree that monitoring is important and in fact we are working on such a monitor right now. > Also, the scenario addressed in 2.2.1 > is specific to a very narrowly-defined class of resource holders who elected the third of > three approaches (not the preferred approach) to participating in the RPKI. To clarify, which 3 approaches do you mean? In 2.2.1 we consider an org B who has its own ASN but chooses not to have its own resource cert; instead, it has org A issue its ROA. (This is one of two recommendations in RFC6480 Section 7.3.2 first paragraph.) In this case, the parent org A can whack org B's ROA in surreptitious ways, without explicitly using revocation lists. In the case where org B has its own resource cert, ROA whacking is more detectable, because it might involve issuing new ROA, grandparenting, etc. We discuss that in Sections 2.2.2-2.2.3, 2.3-2.5. >> -- We show that targeted revocation can be accomplished by entities >> other than a ROA's issuer, some of which may control many ROAs. The >> means by which this is accomplished often looks similar to >> grandparenting. See Sections 2.2.2, 2.2.3, and 2.3 of the report. > > As above, the actions described in these sections are all easily detectable > by the targeted entity. So, the question is what that entity would/could do if > it detects this sort of activity by its parent (or grandparent). Unless the > parent was compelled to whack a ROA by a LEO, there is likely to be a legal remedy > that can be invoked. if a LEO is involved, then the situation is more complex, > but I've been working on a memo that describes remedies for that context as well. > I'll share it when it's been vetted by some more folks. We'll look forward to this -- more information about legal remedies will be useful to inform further investigations on our end. We are particularly curious about how legal recourse would play out in cases where the targeted party is in a different country than the party that whacked its ROA. For example, what if an American organization whacks a ROA for an AS in a different country (or vice versa)? We did some analysis of when a subject in one country can whack a ROA for an AS in another country. See the heatmaps on slide 10-11 of the slide deck: http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf To get these, we took data on the direct-allocations from each RIR, and then used routeviews and RIPE RIS data to determine for each directly-allocated prefix, how many different ASes originate the prefix or any of its subprefixes. We show this in slide 10. To get slide 11, we then use the AS-to-country mappings provided by the RIRs to determine the number of countries that have ASes who originate prefixes that are covered by the directly allocated prefix. (Note we are in the midst of writing up a full report of these results, that I'll share with the list in a month or two.) So, if we suppose that prefixes directly allocated by the RIRs are given their own resource certs, we see that these resource certs can whack ROAs for ASes in multiple countries. (Look at 8/8 or 12/8, for example.) How would takedowns play out if they cross national borders? Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --089e013c6c0e6e5cd904d94ef8fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Steve,

Thanks for your careful reading of our report.=A0 We have = some questions for you inline:

>> -- We show that it is possibl= e to revoke a ROA surreptitiously,
>> through methods other than (= the obvious) revocation lists. See Section
>> 2.2.1 of the report.
>
> The terminology above is not = quite correct, since only one of the five
> "methods" resul= ts in revocation per se. I suggest using the technical
> term "w= hacking" instead. (You're a Princeton grad, so a NJ-inspired term<= br> > of this sort seems appropriate :-)

Yes, exactly.=A0 We should ch= ange all our reports to say "whacked" :)

> Nonetheless, = all of the methods for whacking a ROA described in the paper
> are de= tectable by anyone who monitors the RPKI. One might argue that each
> resource holder should monitor his/her RPKI pub point to detect any ac= tion
> that causes one's ROA to become unverifiable.

We agr= ee that monitoring is important and in fact we are working on such a monito= r right now.

> Also, the scenario addressed in 2.2.1
> is specific to a very= narrowly-defined class of resource holders who elected the third of
>= ; three approaches (not the preferred approach) to participating in the RPK= I.

To=A0clarify, which 3 approaches do you mean?

In 2.2.1 we consider= an org B who has its own ASN but chooses not to have its own resource cert= ; instead, it has org A issue its ROA.=A0 (This is one of two recommendatio= ns in RFC6480 Section 7.3.2 first paragraph.)=A0 In this case, the parent o= rg A can whack org B's ROA in surreptitious ways, without explicitly us= ing revocation lists.

In the case where org B has its own resource cert, ROA whacking is more = detectable, because it might involve issuing new ROA, grandparenting, etc.= =A0 We discuss that in Sections 2.2.2-2.2.3, 2.3-2.5.

>> -- We = show that targeted revocation can be accomplished by entities
>> other than a ROA's issuer, some of which may control many ROAs= . The
>> means by which this is accomplished often looks similar t= o
>> grandparenting. See Sections 2.2.2, 2.2.3, and 2.3 of the rep= ort.
>
> As above, the actions described in these sections are all easi= ly detectable
> by the targeted entity. So, the question is what that= entity would/could do if
> it detects this sort of activity by its p= arent (or grandparent). Unless the
> parent was compelled to whack a ROA by a LEO, there is likely to be a = legal remedy
> that can be invoked. if a LEO is involved, then the si= tuation is more complex,
> but I've been working on a memo that d= escribes remedies for that context as well.
> I'll share it when it's been vetted by some more folks.

= We'll look forward to this -- more information about legal remedies wil= l=A0be=A0useful=A0to=A0inform=A0further investigations on our end.

We= are particularly curious about how legal recourse would play out in cases = where the targeted party is in a different country than the party that whac= ked its ROA.=A0 For example, what if an American organization whacks a ROA = for an AS in a different country (or vice versa)?

We did some analysis of when a subject in one country can whack a ROA fo= r an AS in another country.=A0 See the heatmaps on slide 10-11 of the slide= deck:

http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BF= OC.pdf

To get these, we took data on the direct-allocations from each RIR, an= d then used routeviews and RIPE RIS data to determine for each directly-all= ocated prefix, how many different ASes originate the prefix or any of its s= ubprefixes.=A0 We show this in slide 10.=A0 To get slide 11, we then use th= e AS-to-country mappings provided by the RIRs to determine the number of co= untries that have ASes who originate prefixes that are covered by the direc= tly allocated prefix.=A0 (Note we are in the midst of writing up a full rep= ort of these results, that I'll share with the list in a month or two.)=
=A0
So, if we suppose that prefixes directly allocated by th= e RIRs are given their own resource certs, we see that these resource certs= can whack ROAs for ASes in multiple countries. (Look at 8/8 or 12/8, for e= xample.)=A0 How would takedowns play out if they cross national borders?

Sharon

--
Sharon Goldberg
Computer Science, Boston Universit= y
http://www.= cs.bu.edu/~goldbe

=A0

--089e013c6c0e6e5cd904d94ef8fe-- From danny@tcb.net Mon Apr 1 11:03:34 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B9921E8087 for ; Mon, 1 Apr 2013 11:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.578 X-Spam-Level: X-Spam-Status: No, score=-98.578 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZIGVuctIaSh for ; Mon, 1 Apr 2013 11:03:33 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id A681A21E804A for ; Mon, 1 Apr 2013 11:03:33 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 3117D30008B for ; Mon, 1 Apr 2013 18:03:33 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.friendswithtools.org (Postfix) with ESMTP id E6143300089 for ; Mon, 1 Apr 2013 12:03:32 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 01 Apr 2013 12:03:32 -0600 From: Danny McPherson To: In-Reply-To: References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> Message-ID: <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Apr 1 12:03:33 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 5159cbf542074859731107 X-DSPAM-Factors: 27, Subject*sidr+#+University, 0.01000, Subject*Princeton+#+#+IP, 0.01000, Subject*IP+#+Reachability, 0.01000, Subject*Impacting+#+#+Reachability, 0.01000, Subject*RPKI+Manipulations, 0.01000, Subject*University+#+#+Address, 0.01000, Subject*Princeton+#+#+#+Address, 0.01000, Subject*sidr+#+#+#+IP, 0.01000, Subject*University+Impacting, 0.01000, of+this, 0.01000, Subject*via+#+Manipulations, 0.01000, To*sidr+ietf.org, 0.01000, the+#+of, 0.01000, in+the, 0.01000, From*Danny+#+danny, 0.01000, Subject*Princeton+#+Impacting, 0.01000, a+#+#+#+the, 0.01000, From*Danny+#+#+tcb.net, 0.01000, Subject*sidr+#+#+Impacting, 0.01000, Subject*Re+#+#+University, 0.01000, Subject*IP+Address, 0.01000, Subject*Re+sidr, 0.01000, From*Danny+McPherson, 0.01000, Subject*University+#+#+#+Reachability, 0.01000, with+the, 0.01000, with+a, 0.01000, i+e, 0.01000 Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:03:34 -0000 On 2013-04-01 10:17, Sharon Goldberg wrote: > So, if we suppose that prefixes directly allocated by the RIRs are > given their own resource certs, we see that these resource certs can > whack ROAs for ASes in multiple countries. (Look at 8/8 or 12/8, for > example.)  How would takedowns play out if they cross national > borders? Various flavors of this "whacking" happens a *great deal* today in the DNS operations space, where LEOs engage with registries or registrars because they have operations within direct or MLAT reach, as opposed engaging directly with a registrar, registrant, or the transacting systems / operators themselves. Certainly, RPKI will help some with the latter of these (i.e., whack transacting systems rather than enablers). -danny From eosterweil@verisign.com Mon Apr 1 11:57:37 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE79B21F90F3 for ; Mon, 1 Apr 2013 11:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O0NKEnN6ZDM for ; Mon, 1 Apr 2013 11:57:37 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF8721F90CE for ; Mon, 1 Apr 2013 11:57:29 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKUVnYlXgclK8YdmlQD6ZbDlNTqhTIrZu8@postini.com; Mon, 01 Apr 2013 11:57:36 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r31IvOn7000854; Mon, 1 Apr 2013 14:57:24 -0400 Received: from dul1osterwe-m2.vcorp.ad.vrsn.com ([10.88.29.76]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Apr 2013 14:57:24 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Osterweil, Eric" In-Reply-To: Date: Mon, 1 Apr 2013 14:57:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <865A3DF0-F47C-4A5F-8D47-950738A6A7FA@verisign.com> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> To: Sharon Goldberg X-Mailer: Apple Mail (2.1499) X-OriginalArrivalTime: 01 Apr 2013 18:57:24.0021 (UTC) FILETIME=[BEF4B650:01CE2F0A] Cc: broglek@bu.edu, sidr@ietf.org, eth3rs@gmail.com, dannyc@bu.edu Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:57:38 -0000 On Apr 1, 2013, at 12:17 PM, Sharon Goldberg wrote: > > Nonetheless, all of the methods for whacking a ROA described in the = paper > > are detectable by anyone who monitors the RPKI. One might argue that = each=20 > > resource holder should monitor his/her RPKI pub point to detect any = action > > that causes one's ROA to become unverifiable. >=20 > We agree that monitoring is important and in fact we are working on = such a monitor right now. Yeah, actually, we've had RPKISpider up and running for several months: http://rpkispider.verisignlabs.com/ and @RPKIUpdateBot tweeting all global repo changes for longer: https://twitter.com/RPKIUpdateBot Tweets show resource holders how they can view their own delegations and = watch in real time _today_. For example, = http://rpkispider.verisignlabs.com/rpki-rescert-chain.cgi?p=3D194.126.136.= 0/21-24&r=3D6254 Its metrics also serve as a pretty good detection mechanisms for = outages. ;) We're a little behind on a writeup, but we've been known to be active on = email. ;) Eric= From jcurran@arin.net Mon Apr 1 13:37:39 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEE421E8053 for ; Mon, 1 Apr 2013 13:37:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fMvqY+iZwV1 for ; Mon, 1 Apr 2013 13:37:38 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 21A6721E8051 for ; Mon, 1 Apr 2013 13:37:38 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id B9991165195; Mon, 1 Apr 2013 16:37:37 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 06F1416518B; Mon, 1 Apr 2013 16:37:33 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 1 Apr 2013 16:36:57 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Mon, 1 Apr 2013 16:37:31 -0400 From: John Curran To: Danny McPherson Thread-Topic: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations Thread-Index: AQHOLxi7J8r/o/vLLEebRqd2la6FBA== Date: Mon, 1 Apr 2013 20:37:31 +0000 Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> In-Reply-To: <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <391CF8B5C78A8040A8CC8EDD8BD281BA@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:37:39 -0000 On Apr 1, 2013, at 2:03 PM, Danny McPherson wrote: > On 2013-04-01 10:17, Sharon Goldberg wrote: >=20 >> So, if we suppose that prefixes directly allocated by the RIRs are >> given their own resource certs, we see that these resource certs can >> whack ROAs for ASes in multiple countries. (Look at 8/8 or 12/8, for >> example.) How would takedowns play out if they cross national >> borders? >=20 > Various flavors of this "whacking" happens a *great deal* today in the DN= S operations space, where LEOs engage with registries or registrars because= they have operations within direct or MLAT reach, as opposed engaging dire= ctly with a registrar, registrant, or the transacting systems / operators t= hemselves. Certainly, RPKI will help some with the latter of these (i.e., = whack transacting systems rather than enablers). The present equivalent for the RIRs would be LEO's engaging in orders to change the address holder associated with an IP block, and I am=20 happy to say that (at least in ARIN's case) that we have not seen any=20 such requests to date. We do work extremely well with law enforcement,=20 but relations are predominantly focused on obtaining information for=20 various investigations. ARIN serves more than 25 different countries,=20 and as much as possible expects to see LEO requests to involve LEA in the country of the resource holder except in extremis cases. An actual=20 uncoordinated LEO order to change a registrant on an IP block could be=20 rather problematic; there is some chance that I would end up needing a=20 toothbrush and good reading material depending on the country of the=20 registrant & nature of the circumstances. FYI, /John John Curran President and CEO ARIN From danny@tcb.net Mon Apr 1 16:24:01 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36C721E8104 for ; Mon, 1 Apr 2013 16:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.508 X-Spam-Level: X-Spam-Status: No, score=-99.508 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLf7IBkLXfAO for ; Mon, 1 Apr 2013 16:24:01 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 472FE21E80FF for ; Mon, 1 Apr 2013 16:24:01 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id E1D8830008D for ; Mon, 1 Apr 2013 23:24:00 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.friendswithtools.org (Postfix) with ESMTP id 5C7B330007F; Mon, 1 Apr 2013 17:24:00 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 01 Apr 2013 17:24:00 -0600 From: Danny McPherson To: John Curran In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> Message-ID: X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Apr 1 17:24:00 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 515a171042071021813181 X-DSPAM-Factors: 27, to+#+#+#+to, 0.01000, to+#+the, 0.01000, to+#+#+in, 0.01000, and+#+#+#+to, 0.01000, and+the, 0.01000, the+#+#+the, 0.01000, the+#+#+the, 0.01000, Subject*sidr+#+University, 0.01000, Subject*Princeton+#+#+IP, 0.01000, Subject*IP+#+Reachability, 0.01000, Subject*Impacting+#+#+Reachability, 0.01000, for+the, 0.01000, Subject*RPKI+Manipulations, 0.01000, Subject*University+#+#+Address, 0.01000, Subject*Princeton+#+#+#+Address, 0.01000, Subject*sidr+#+#+#+IP, 0.01000, Subject*University+Impacting, 0.01000, the+#+#+of, 0.01000, to+#+#+#+the, 0.01000, Subject*via+#+Manipulations, 0.01000, on+the, 0.01000, the+#+#+#+the, 0.01000, the+#+of, 0.01000, the+#+of, 0.01000, in+the, 0.01000, From*Danny+#+danny, 0.01000, Subject*Princeton+#+Impacting, 0.01000 Cc: sidr@ietf.org Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 23:24:01 -0000 On 2013-04-01 14:37, John Curran wrote: > The present equivalent for the RIRs would be LEO's engaging in orders > to change the address holder associated with an IP block, and I am > happy to say that (at least in ARIN's case) that we have not seen any > such requests to date. That's intuitive given that RIRs don't have an operational role in connectivity today. E.g., you can do whatever you want, operators don't need you to route stuff. The crux is that RPKI will change that. > We do work extremely well with law enforcement, > but relations are predominantly focused on obtaining information for > various investigations. ARIN serves more than 25 different > countries, > and as much as possible expects to see LEO requests to involve LEA in > the country of the resource holder except in extremis cases. An > actual > uncoordinated LEO order to change a registrant on an IP block could > be > rather problematic; there is some chance that I would end up needing > a > toothbrush and good reading material depending on the country of the > registrant & nature of the circumstances. Heh.. We receive hundreds of court orders (many sealed) a year involving literally thousands of domain names (and varying actions) and the registrars, registrants, and resources to which they map are all over the globe. It's not something we're particularly fond of for an array of reasons, as you can imagine, but we usually don't have any choice. Fortunately, RPKI will provide them a more effective alternative ;-) -danny > > FYI, > /John > > John Curran > President and CEO > ARIN From jcurran@arin.net Mon Apr 1 19:31:17 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854AC21E80F1 for ; Mon, 1 Apr 2013 19:31:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gLVj1dLz3kZ for ; Mon, 1 Apr 2013 19:31:17 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id D350721E80E4 for ; Mon, 1 Apr 2013 19:31:16 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 887DD1651BF; Mon, 1 Apr 2013 22:31:16 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id C9F991651BA; Mon, 1 Apr 2013 22:31:11 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 1 Apr 2013 22:30:28 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Mon, 1 Apr 2013 22:31:03 -0400 From: John Curran To: Danny McPherson Thread-Topic: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations Thread-Index: AQHOLxi7J8r/o/vLLEebRqd2la6FBJjCRNcAgAA0RAA= Date: Tue, 2 Apr 2013 02:31:03 +0000 Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 02:31:17 -0000 On Apr 1, 2013, at 7:24 PM, Danny McPherson wrote: > On 2013-04-01 14:37, John Curran wrote: >=20 >> The present equivalent for the RIRs would be LEO's engaging in orders >> to change the address holder associated with an IP block, and I am >> happy to say that (at least in ARIN's case) that we have not seen any >> such requests to date. >=20 > That's intuitive given that RIRs don't have an operational role in connec= tivity today. E.g., you can do whatever you want, operators don't need you= to route stuff. The crux is that RPKI will change that. I'm not certain its all that different (particularly not in the early stages of RPKI deployment)... In theory, we could receive an order to reassign an address block to another party (with similar consequences today for those following whois and or irr data.) From past discussions, most law enforcement folks realize that IP address blocks are generally assigned to ISPs and used to serve many, many customers. Except in some interesting corner cases, it's generally insufficiently precise for their=20 needs (as opposed to domain names that serve single business interests)=20 > Heh.. We receive hundreds of court orders (many sealed) a year involving= literally thousands of domain names (and varying actions) and the registra= rs, registrants, and resources to which they map are all over the globe. I= t's not something we're particularly fond of for an array of reasons, as yo= u can imagine, but we usually don't have any choice. Fortunately, RPKI wil= l provide them a more effective alternative ;-) Indeed, there will be some that see RPKI as a possible new approach for such matters. The registry needs to be consistent (i.e. across registration data, Whois publication, and RPKI publication) and we'll certainly seek to prevent RPKI-specific actions as inconsistent with=20 our mission. Also, we have some past success dealing with non-sensical=20 directives, e.g. an order to reassign a single IP address from the=20 midst of a ISP's IP block to another party, but to the extent we get=20 a lawful order to change the address block registered to a party in=20 their jurisdiction, it's going to be fairly challenging situation. Our best bet may be simply continuing to educate law enforcement about=20 the difficulty of attempting granular actions on an IP address block=20 basis (as contrasted to the DNS layer); from your report, it seems that=20 they've gotten the message so far... ;-) FYI, /John =20 John Curran President and CEO ARIN From shane@castlepoint.net Mon Apr 1 19:36:14 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8709021E80B0 for ; Mon, 1 Apr 2013 19:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oGigC-A5mgc for ; Mon, 1 Apr 2013 19:36:13 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8B14A21E80F1 for ; Mon, 1 Apr 2013 19:36:13 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 3348C300073 for ; Tue, 2 Apr 2013 02:36:13 +0000 (UTC) Received: from mbp.castlepoint.net (184-96-123-182.hlrn.qwest.net [184.96.123.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id CD871300062 for ; Mon, 1 Apr 2013 20:36:12 -0600 (MDT) From: Shane Amante Content-Type: multipart/alternative; boundary="Apple-Mail=_B1CB1228-F5AD-44CB-86E5-C89B8F2783E0" Message-Id: <9BAD9CCC-D6C7-467C-95CF-92BA47494E78@castlepoint.net> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Mon, 1 Apr 2013 20:36:11 -0600 References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> To: sidr@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Apr 1 20:36:13 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 515a441d42076036018065 X-DSPAM-Factors: 27, 2013+at, 0.01000, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, Mime-Version*OS+X, 0.01000, and+then, 0.01000, and+then, 0.01000, the+#+#+#+to, 0.01000, the+#+#+#+to, 0.01000, and+#+#+#+to, 0.01000, and+#+#+#+to, 0.01000, From*Amante+shane, 0.01000, be+#+#+#+the, 0.01000, be+#+#+#+the, 0.01000, as+well, 0.01000, as+well, 0.01000, the+#+#+the, 0.01000, the+#+#+the, 0.01000, Subject*sidr+#+University, 0.01000, of+#+#+of, 0.01000, of+#+#+of, 0.01000, Subject*Princeton+#+#+IP, 0.01000, the+#+to, 0.01000, the+#+to, 0.01000, be+#+to, 0.01000, be+#+to, 0.01000 Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 02:36:14 -0000 --Apple-Mail=_B1CB1228-F5AD-44CB-86E5-C89B8F2783E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 1, 2013, at 10:17 AM, Sharon Goldberg wrote: [--snip--] > > As above, the actions described in these sections are all easily = detectable > > by the targeted entity. So, the question is what that entity = would/could do if > > it detects this sort of activity by its parent (or grandparent). = Unless the > > parent was compelled to whack a ROA by a LEO, there is likely to be = a legal remedy > > that can be invoked. if a LEO is involved, then the situation is = more complex, > > but I've been working on a memo that describes remedies for that = context as well. > > I'll share it when it's been vetted by some more folks. >=20 > We'll look forward to this -- more information about legal remedies = will be useful to inform further investigations on our end. >=20 > We are particularly curious about how legal recourse would play out in = cases where the targeted party is in a different country than the party = that whacked its ROA. For example, what if an American organization = whacks a ROA for an AS in a different country (or vice versa)? >=20 > We did some analysis of when a subject in one country can whack a ROA = for an AS in another country. See the heatmaps on slide 10-11 of the = slide deck: >=20 > http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf >=20 > To get these, we took data on the direct-allocations from each RIR, = and then used routeviews and RIPE RIS data to determine for each = directly-allocated prefix, how many different ASes originate the prefix = or any of its subprefixes. We show this in slide 10. To get slide 11, = we then use the AS-to-country mappings provided by the RIRs to determine = the number of countries that have ASes who originate prefixes that are = covered by the directly allocated prefix. (Note we are in the midst of = writing up a full report of these results, that I'll share with the list = in a month or two.) > =20 > So, if we suppose that prefixes directly allocated by the RIRs are = given their own resource certs, we see that these resource certs can = whack ROAs for ASes in multiple countries. (Look at 8/8 or 12/8, for = example.) How would takedowns play out if they cross national borders? As one operator whose worldwide routing/operations could be negatively = impacted by the above, it would be nice to have a concise statement = about what is/was the original intent of the design of the RPKI with = respect to the above. In addition, it would be useful to see if any = potential remedies/solutions may be employed (and, any associated = overhead/delays/*costs*/etc. they incur) that may be used to mitigate = them /before/ they manifest themself in the network, at which point = operators will be obligated to stop using those 'trusted information = repositories' to directly inform routing. Regardless ... good work, Sharon & Co. -shane= --Apple-Mail=_B1CB1228-F5AD-44CB-86E5-C89B8F2783E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 goldbe@cs.bu.edu> = wrote:
[--snip--]

> As = above, the actions described in these sections are all easily = detectable
> by the targeted entity. So, the question is what that = entity would/could do if
> it detects this sort of activity by its = parent (or grandparent). Unless the
> parent was compelled to whack a ROA by a LEO, there is likely to be = a legal remedy
> that can be invoked. if a LEO is involved, then = the situation is more complex,
> but I've been working on a memo = that describes remedies for that context as well.
> I'll share it when it's been vetted by some more folks.

We'll = look forward to this -- more information about legal remedies = will be useful to inform further investigations = on our end.

We are particularly curious about how legal recourse = would play out in cases where the targeted party is in a different = country than the party that whacked its ROA.  For example, what if = an American organization whacks a ROA for an AS in a different country = (or vice versa)?

We did some analysis of when a subject in one = country can whack a ROA for an AS in another country.  See the = heatmaps on slide 10-11 of the slide deck:

http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf=

To get these, we took data on the direct-allocations from each RIR, = and then used routeviews and RIPE RIS data to determine for each = directly-allocated prefix, how many different ASes originate the prefix = or any of its subprefixes.  We show this in slide 10.  To get = slide 11, we then use the AS-to-country mappings provided by the RIRs to = determine the number of countries that have ASes who originate prefixes = that are covered by the directly allocated prefix.  (Note we are in = the midst of writing up a full report of these results, that I'll share = with the list in a month or two.)
 
So, if we suppose that prefixes directly allocated = by the RIRs are given their own resource certs, we see that these = resource certs can whack ROAs for ASes in multiple countries. (Look at = 8/8 or 12/8, for example.)  How would takedowns play out if they = cross national borders?

As one operator = whose worldwide routing/operations could be negatively impacted by the = above, it would be nice to have a concise statement about what is/was = the original intent of the design of the RPKI with respect to the above. =  In addition, it would be useful to see if any potential = remedies/solutions may be employed (and, any associated = overhead/delays/*costs*/etc. they incur) that may be used to mitigate = them /before/ they manifest themself in the network, at which point = operators will be obligated to stop using those 'trusted information = repositories' to directly inform routing.

Regardless = ... good work, Sharon & = Co.

-shane
= --Apple-Mail=_B1CB1228-F5AD-44CB-86E5-C89B8F2783E0-- From danny@tcb.net Tue Apr 2 06:53:23 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDD321F8539 for ; Tue, 2 Apr 2013 06:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.972 X-Spam-Level: X-Spam-Status: No, score=-99.972 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7Dxec22pwiu for ; Tue, 2 Apr 2013 06:53:22 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id C7B5921F84F8 for ; Tue, 2 Apr 2013 06:53:22 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 83C9F30007F for ; Tue, 2 Apr 2013 13:53:22 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.friendswithtools.org (Postfix) with ESMTP id EEEC3300079; Tue, 2 Apr 2013 07:53:21 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Apr 2013 07:53:21 -0600 From: Danny McPherson To: John Curran In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> Message-ID: X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Apr 2 07:53:22 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 515ae2d242075312329356 X-DSPAM-Factors: 27, to+#+#+#+to, 0.01000, to+#+#+#+to, 0.01000, to+#+the, 0.01000, to+#+#+in, 0.01000, to+#+#+in, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, the+#+#+#+to, 0.01000, and+#+#+#+to, 0.01000, and+#+#+#+to, 0.01000, and+the, 0.01000, as+well, 0.01000, the+#+#+the, 0.01000, Subject*sidr+#+University, 0.01000, to+#+#+and, 0.01000, Subject*Princeton+#+#+IP, 0.01000, the+#+#+a, 0.01000, Subject*IP+#+Reachability, 0.01000, Subject*Impacting+#+#+Reachability, 0.01000, Subject*RPKI+Manipulations, 0.01000, Subject*University+#+#+Address, 0.01000, to+#+a, 0.01000, as+a, 0.01000, Subject*Princeton+#+#+#+Address, 0.01000, to+the, 0.01000, to+the, 0.01000, Subject*sidr+#+#+#+IP, 0.01000, on+this, 0.01000 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:53:23 -0000 On 2013-04-01 20:31, John Curran wrote: > > Indeed, there will be some that see RPKI as a possible new approach > for such matters. The registry needs to be consistent (i.e. across > registration data, Whois publication, and RPKI publication) and we'll > certainly seek to prevent RPKI-specific actions as inconsistent with > our mission. Speaking of inconsistencies in the RPKI, what's ARIN and the NRO's status on getting to a single trust anchor? > Also, we have some past success dealing with non-sensical > directives, e.g. an order to reassign a single IP address from the > midst of a ISP's IP block to another party, but to the extent we get > a lawful order to change the address block registered to a party in > their jurisdiction, it's going to be fairly challenging situation. Yeah, they were nonsensical in the past and present role of ARIN, not in an RPKI-enabled world where revocation or transfer or inaccessibility will have some impacted on the routability of the address block in question. > Our best bet may be simply continuing to educate law enforcement > about > the difficulty of attempting granular actions on an IP address block > basis (as contrasted to the DNS layer); I suspect they long ago realized RIRs have traditionally had little to no role in this, and they reach out to ISPs where possible. Again, I'd wager this will change, but alas, only time will tell. > from your report, it seems that they've gotten the message so far... > ;-) I doubt your messaging has impacted this, but if so, you might tell them all the reasons it's stupid as well, and simply forces diffusion, etc.. Actually, does ARIN have a public statement on this "message" you're talking about - i.e., apparently why DNS takedowns are a good idea and effective and LEOs should go that route v. contacting ISPs or hosting providers, etc..? I'd like to pass that along to our compliance and abuse office for inclusive in their LEO package (and selfishly, understand the logic)? Thanks John, -danny -danny From jcurran@arin.net Tue Apr 2 07:27:07 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D82921F8AE7 for ; Tue, 2 Apr 2013 07:27:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6cqNHJt+o2f for ; Tue, 2 Apr 2013 07:27:06 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 7D17121F86C3 for ; Tue, 2 Apr 2013 07:27:06 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 30FAC1651E7; Tue, 2 Apr 2013 10:27:06 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id A7D231651C4; Tue, 2 Apr 2013 10:27:01 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 2 Apr 2013 10:26:23 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 2 Apr 2013 10:27:01 -0400 From: John Curran To: Danny McPherson Thread-Topic: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations Thread-Index: AQHOLxi7J8r/o/vLLEebRqd2la6FBJjCRNcAgAA0RACAAL6hgIAACWiA Date: Tue, 2 Apr 2013 14:26:59 +0000 Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAB4B9A@CHAXCH01.corp.arin.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <8303B4DE39D50F42AA48DCC55FC31E82@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:27:07 -0000 On Apr 2, 2013, at 9:53 AM, Danny McPherson wrote: >=20 > Speaking of inconsistencies in the RPKI, what's ARIN and the NRO's status= on getting to a single trust anchor? I believe that ICANN and the RIR technical staffs are busy trying to=20 document a proposed structure and operation to bring to the IETF (e.g. how does one provide for transfers between regions without having an=20 an impact at 0/0 each time...) However, that's somewhat independent of your question... Do you see inconsistent data right now from following the RIR CA trees? A single trust anchor is going to point to the same data, so if you see any issues, please speak up. > Yeah, they were nonsensical in the past and present role of ARIN, not in = an RPKI-enabled world where revocation or transfer or inaccessibility will = have some impacted on the routability of the address block in question. You keep repeating that assertion, but note that even in today's world we could be ordered to reclaim and reassign a block with similar effect. It may not be "real time" but there are plenty of folks who follow both the daily issued files as well as derivative filter lists. It is also true of various routing registries. Even after deployment of RPKI, there will be some fairly long period where loss of the covering ROA _alone_ is=20 likely to have little impact since the routing is still there, and we don't= =20 seem to have any documentation suggesting to _only_ listen to routes that=20 are known valid. Loss of ROA coverage exposes one to further exploits,=20 but per existing guidance it should not result in connectivity impacts=20 (just as leaving one's seatbelt off doesn't generate an auto accident...) > Actually, does ARIN have a public statement on this "message" you're talk= ing about - i.e., apparently why DNS takedowns are a good idea and effectiv= e and LEOs should go that route v. contacting ISPs or hosting providers, et= c..? I'd like to pass that along to our compliance and abuse office for in= clusive in their LEO package (and selfishly, understand the logic)? Danny, I never said "DNS takedowns are a good idea"; I said we "educate=20 law enforcement about the difficulty of attempting granular actions on=20 an IP address block basis." To the extent that one accepts that LEA folks are going to sometimes impact the network for their purposes, it is better= =20 if they use the most focused tools available. If that turns out to be the DNS system, then I imagine that's where they turn next; the fact that one can impact connectivity via orders against the DNS infrastructure does not automatically mean we shouldn't deploy DNS, only that we should do so with= =20 understanding of that potential (and the same could be said for RPKI...) Thanks! /John John Curran President and CEO ARIN From shane@castlepoint.net Tue Apr 2 07:53:23 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3377821F84D8 for ; Tue, 2 Apr 2013 07:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZUEouHH2gmJ for ; Tue, 2 Apr 2013 07:53:22 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id A580C21F84EF for ; Tue, 2 Apr 2013 07:53:22 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 5EFB2300078 for ; Tue, 2 Apr 2013 14:53:22 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id CD874300054; Tue, 2 Apr 2013 08:53:21 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAB4B9A@CHAXCH01.corp.arin.net> Date: Tue, 2 Apr 2013 08:53:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <184F460B-1EDB-4C84-8EFB-38643B71AAF5@castlepoint.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00 B3748FAB4B9A@CHAXCH01.corp.arin.net> To: John Curran X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Apr 2 08:53:22 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 515af0e242071043917877 X-DSPAM-Factors: 27, 2013+at, 0.01000, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, have+#+#+#+the, 0.01000, have+#+#+#+the, 0.01000, that+are, 0.01000, that+are, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, Mime-Version*OS+X, 0.01000, not+be, 0.01000, the+#+#+#+to, 0.01000, and+#+#+#+to, 0.01000, From*Amante+shane, 0.01000, a+#+to, 0.01000, as+well, 0.01000, the+#+#+the, 0.01000, Subject*sidr+#+University, 0.01000, Subject*Princeton+#+#+IP, 0.01000, the+#+#+a, 0.01000, it+is, 0.01000, be+#+to, 0.01000, Subject*IP+#+Reachability, 0.01000, Subject*Impacting+#+#+Reachability, 0.01000, is+#+to, 0.01000, Subject*RPKI+Manipulations, 0.01000, Subject*University+#+#+Address, 0.01000, the+address, 0.01000 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:53:23 -0000 John, See below. On Apr 2, 2013, at 8:26 AM, John Curran wrote: > On Apr 2, 2013, at 9:53 AM, Danny McPherson wrote: [--snip--] >> Yeah, they were nonsensical in the past and present role of ARIN, not = in an RPKI-enabled world where revocation or transfer or inaccessibility = will have some impacted on the routability of the address block in = question. >=20 > You keep repeating that assertion, but note that even in today's world > we could be ordered to reclaim and reassign a block with similar = effect. > It may not be "real time" but there are plenty of folks who follow = both > the daily issued files as well as derivative filter lists. It is also > true of various routing registries. Even after deployment of RPKI, = there > will be some fairly long period where loss of the covering ROA _alone_ = is=20 > likely to have little impact since the routing is still there, and we = don't=20 > seem to have any documentation suggesting to _only_ listen to routes = that=20 > are known valid. Loss of ROA coverage exposes one to further = exploits,=20 > but per existing guidance it should not result in connectivity impacts=20= > (just as leaving one's seatbelt off doesn't generate an auto = accident...) Personally, I think there's a significant difference in "today's world" = vs. a "RPKI-enabled world". Specifically, in today's world, it's = typically only upstream SP's that are using such information as a means = to apply prefix+Origin_AS filters against their directly attached = customers (and, customers of customers). In my understanding of the = future promise-land that is the RPKI, ROA information will *not only* be = used by SP's to filter against directly attached customers (and, = customers of customers) like it is today ... but *also* on all = interconnect (peering) circuits and even by third-party SP's who have no = direct and, likely, no indirect relationship with the resource-holder in = the first place. Thus, what Danny speaks of (and, I share a similar = concern) is that either an operational mistake/bug in the RPKI and/or = law-enforcement action against the RPKI /will/ result in a much, much = larger denial-of-service, perhaps denying that resource holder an = ability to receive packets on the Internet for a substantial portion of = time. That's a /substantially/ different operating model from today's = world where, more often than not, it's typically only the customer's = upstream SP's to modify/update a filter-list, which can be done in = *minutes* vs. how long in the RPKI ... including time for third-parties = to fetch and update and make state changes in the network? -shane= From jcurran@arin.net Tue Apr 2 08:30:37 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798A721F8B19 for ; Tue, 2 Apr 2013 08:30:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb02Q3fs-Srm for ; Tue, 2 Apr 2013 08:30:36 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB5921F8B04 for ; Tue, 2 Apr 2013 08:30:36 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 4351E213596; Tue, 2 Apr 2013 11:30:36 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 9BC5D2135A6; Tue, 2 Apr 2013 11:30:31 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 2 Apr 2013 11:30:22 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 2 Apr 2013 11:30:30 -0400 From: John Curran To: Shane Amante Thread-Topic: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations Thread-Index: AQHOLxi7J8r/o/vLLEebRqd2la6FBJjCRNcAgAA0RACAAL6hgIAACWiAgAAHWYCAAApkgA== Date: Tue, 2 Apr 2013 15:30:29 +0000 Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAB5B60@CHAXCH01.corp.arin.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00 B3748FAB4B9A@CHAXCH01.corp.arin.net> <184F460B-1EDB-4C84-8EFB-38643B71AAF5@castlepoint.net> In-Reply-To: <184F460B-1EDB-4C84-8EFB-38643B71AAF5@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:30:37 -0000 On Apr 2, 2013, at 10:53 AM, Shane Amante wrote: >> You keep repeating that assertion, but note that even in today's world >> we could be ordered to reclaim and reassign a block with similar effect. >> It may not be "real time" but there are plenty of folks who follow both >> the daily issued files as well as derivative filter lists. It is also >> true of various routing registries. Even after deployment of RPKI, ther= e >> will be some fairly long period where loss of the covering ROA _alone_ i= s=20 >> likely to have little impact since the routing is still there, and we do= n't=20 >> seem to have any documentation suggesting to _only_ listen to routes tha= t=20 >> are known valid. Loss of ROA coverage exposes one to further exploits,= =20 >> but per existing guidance it should not result in connectivity impacts=20 >> (just as leaving one's seatbelt off doesn't generate an auto accident...= ) >=20 > Personally, I think there's a significant difference in "today's world" v= s. a "RPKI-enabled world". Specifically, in today's world, it's typically = only upstream SP's that are using such information as a means to apply pref= ix+Origin_AS filters against their directly attached customers (and, custom= ers of customers). In my understanding of the future promise-land that is = the RPKI, ROA information will *not only* be used by SP's to filter against= directly attached customers (and, customers of customers) like it is today= ... but *also* on all interconnect (peering) circuits and even by third-pa= rty SP's who have no direct and, likely, no indirect relationship with the = resource-holder in the first place. That's definitely a possible long-term outcome. > Thus, what Danny speaks of (and, I share a similar concern) is that eithe= r an operational mistake/bug in the RPKI and/or law-enforcement action agai= nst the RPKI /will/ result in a much, much larger denial-of-service, perhap= s denying that resource holder an ability to receive packets on the Interne= t for a substantial portion of time. Indeed. Of course, that same outcome can effectively be had today (for an= y=20 given IP address block) via one handful of court orders directed to the lar= ger=20 ISP backbones. FYI, /John From danny@tcb.net Tue Apr 2 08:58:30 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2394B21F8574 for ; Tue, 2 Apr 2013 08:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.127 X-Spam-Level: X-Spam-Status: No, score=-100.127 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCkOqq6mHY0j for ; Tue, 2 Apr 2013 08:58:29 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id CEE4921F855F for ; Tue, 2 Apr 2013 08:58:29 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 90C99300035 for ; Tue, 2 Apr 2013 15:58:29 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.friendswithtools.org (Postfix) with ESMTP id 6D8C330000E for ; Tue, 2 Apr 2013 09:58:29 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Apr 2013 09:58:29 -0600 From: Danny McPherson To: In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAB5B60@CHAXCH01.corp.arin.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00 B3748FAB4B9A@CHAXCH01.corp.arin.net> <184F460B-1EDB-4C84-8EFB-38643B71AAF5@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB5B60@CHAXCH01.corp.arin.net> Message-ID: X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Apr 2 09:58:29 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 515b002542071208410885 X-DSPAM-Factors: 27, Subject*sidr+#+University, 0.01000, Subject*Princeton+#+#+IP, 0.01000, Subject*IP+#+Reachability, 0.01000, On+#+04, 0.01000, Subject*Impacting+#+#+Reachability, 0.01000, Subject*RPKI+Manipulations, 0.01000, Subject*University+#+#+Address, 0.01000, Subject*Princeton+#+#+#+Address, 0.01000, to+the, 0.01000, Subject*sidr+#+#+#+IP, 0.01000, Subject*University+Impacting, 0.01000, Subject*via+#+Manipulations, 0.01000, John+Curran, 0.01000, To*sidr+ietf.org, 0.01000, 2013+04, 0.01000, From*Danny+#+danny, 0.01000, Subject*Princeton+#+Impacting, 0.01000, From*Danny+#+#+tcb.net, 0.01000, part+of, 0.01000, Subject*sidr+#+#+Impacting, 0.01000, Subject*Re+#+#+University, 0.01000, Subject*IP+Address, 0.01000, Subject*Re+sidr, 0.01000, From*Danny+McPherson, 0.01000, Subject*University+#+#+#+Reachability, 0.01000, Subject*Re+#+Princeton, 0.01000, Subject*via+RPKI, 0.01000 Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:58:30 -0000 On 2013-04-02 09:30, John Curran wrote: > Indeed. Of course, that same outcome can effectively be had today > (for any > given IP address block) via one handful of court orders directed to > the larger > ISP backbones. Assuming those backbones operate within jurisdictional or MLAT reach, as opposed to where an RIR falls jurisdictional. But yes, this was indeed part of my earlier point. -danny From danny@tcb.net Tue Apr 2 09:03:02 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C4B21F8CF7 for ; Tue, 2 Apr 2013 09:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.205 X-Spam-Level: X-Spam-Status: No, score=-100.205 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVnu47x4h4qT for ; Tue, 2 Apr 2013 09:03:01 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 33B3721F8CF4 for ; Tue, 2 Apr 2013 09:02:59 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id DC758300056 for ; Tue, 2 Apr 2013 16:02:58 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.friendswithtools.org (Postfix) with ESMTP id 80F2F30000E; Tue, 2 Apr 2013 10:02:58 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Apr 2013 10:02:58 -0600 From: Danny McPherson To: John Curran In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAB4B9A@CHAXCH01.corp.arin.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAB4B9A@CHAXCH01.corp.arin.net> Message-ID: <43525ae3fae7e3c9a5e12062c693a7ba@tcb.net> X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Apr 2 10:02:58 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 515b013242071883110753 X-DSPAM-Factors: 27, 2013+at, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, and+#+#+#+to, 0.01000, and+the, 0.01000, and+the, 0.01000, Subject*sidr+#+University, 0.01000, Subject*Princeton+#+#+IP, 0.01000, 2013+#+9, 0.01000, Subject*IP+#+Reachability, 0.01000, To*John+Curran, 0.01000, On+#+04, 0.01000, Subject*Impacting+#+#+Reachability, 0.01000, Subject*RPKI+Manipulations, 0.01000, Subject*University+#+#+Address, 0.01000, to+#+a, 0.01000, Subject*Princeton+#+#+#+Address, 0.01000, to+the, 0.01000, Subject*sidr+#+#+#+IP, 0.01000, Subject*University+Impacting, 0.01000, Subject*via+#+Manipulations, 0.01000, Cc*sidr+#+list, 0.01000, John+Curran, 0.01000, I+think, 0.01000, 2013+04, 0.01000, in+the, 0.01000, that+#+#+the, 0.01000, 9+#+AM, 0.01000 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:03:02 -0000 On 2013-04-02 08:26, John Curran wrote: > On Apr 2, 2013, at 9:53 AM, Danny McPherson wrote: >> >> Speaking of inconsistencies in the RPKI, what's ARIN and the NRO's >> status on getting to a single trust anchor? > > I believe that ICANN and the RIR technical staffs are busy trying to > document a proposed structure and operation to bring to the IETF > (e.g. > how does one provide for transfers between regions without having an > an impact at 0/0 each time...) > > However, that's somewhat independent of your question... No, that was precisely what my question was. As for today, the architecture permits such collisions, which I think is the issue most agree is, err.. suboptimal. -danny From shane@castlepoint.net Tue Apr 2 09:27:04 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BAC21F8E46 for ; Tue, 2 Apr 2013 09:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeLSR+j3w6UH for ; Tue, 2 Apr 2013 09:27:03 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2776B21F8E2C for ; Tue, 2 Apr 2013 09:27:03 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id D77D9300055 for ; Tue, 2 Apr 2013 16:27:02 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id A955A300054; Tue, 2 Apr 2013 10:27:02 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: Date: Tue, 2 Apr 2013 10:27:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <794B6B21-E645-4941-B7A5-C3A96274FF84@castlepoint.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00 B3748FAB4B9A@CHAXCH01.corp.arin.net> <184F460B-1EDB-4C84-8EFB-38643B71AAF5@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB5B60@CHAXCH01.corp.arin.net> To: Danny McPherson X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Apr 2 10:27:02 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 515b06d642071241720893 X-DSPAM-Factors: 27, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+in, 0.01000, On+Apr, 0.01000, On+#+#+#+09, 0.01000, Mime-Version*OS+X, 0.01000, and+then, 0.01000, address+block, 0.01000, From*Amante+shane, 0.01000, be+#+#+#+the, 0.01000, Subject*sidr+#+University, 0.01000, Subject*Princeton+#+#+IP, 0.01000, have+to, 0.01000, 2013+#+9, 0.01000, Subject*IP+#+Reachability, 0.01000, On+#+04, 0.01000, Subject*Impacting+#+#+Reachability, 0.01000, Subject*RPKI+Manipulations, 0.01000, Subject*University+#+#+Address, 0.01000, Mime-Version*X+#+#+1503, 0.01000, Subject*Princeton+#+#+#+Address, 0.01000, to+the, 0.01000, to+the, 0.01000, Subject*sidr+#+#+#+IP, 0.01000, Subject*University+Impacting, 0.01000, a+#+#+to, 0.01000, Subject*IP+#+#+via, 0.01000 Cc: sidr@ietf.org Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:27:04 -0000 On Apr 2, 2013, at 9:58 AM, Danny McPherson wrote: > On 2013-04-02 09:30, John Curran wrote: >=20 >> Indeed. Of course, that same outcome can effectively be had today = (for any >> given IP address block) via one handful of court orders directed to = the larger >> ISP backbones. >=20 > Assuming those backbones operate within jurisdictional or MLAT reach, = as opposed to where an RIR falls jurisdictional. >=20 > But yes, this was indeed part of my earlier point. IMO, there is still one key difference. ISP's are _directly_ involved = in receiving such orders, evaluating them for validity, applicability = and then carrying them out. This can also include providing a heads-up = to operations teams, in that SP, that a change in configuration to = effect it was "purposeful", thus saving substantial time + OpEx not = trying to track down a "general connectivity issue" that a customer = calls in and reports to the SP. OTOH, with the RPKI ... the actions carried out by, for example, an RIR = will have to be without consultation of the ISP(s) with the directly = attached customer, in the case of sealed orders. How does the SP know = that a certificate was revoked due: a) a bug; b) lack of payment to = their RIR; or, c) a lawful order? And, more importantly, = could/should/would ISP's act differently, in terms of routing on their = networks in any of those cases? It's one thing for an operator to have direct influence/knowledge re: = actions it takes on their own network, it's another matter entirely when = third-parties have that control over your operations, particularly = without any recourse. -shane= From jcurran@arin.net Tue Apr 2 10:22:43 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFED21F8CCB for ; Tue, 2 Apr 2013 10:22:43 -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, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIb26WgoMuXt for ; Tue, 2 Apr 2013 10:22:43 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2FF21F8CBE for ; Tue, 2 Apr 2013 10:22:42 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 077DD21364E; Tue, 2 Apr 2013 13:22:12 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 6F09C213602; Tue, 2 Apr 2013 13:22:07 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 2 Apr 2013 13:21:28 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 2 Apr 2013 13:22:06 -0400 From: John Curran To: Shane Amante Thread-Topic: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations Thread-Index: AQHOLxi7J8r/o/vLLEebRqd2la6FBA== Date: Tue, 2 Apr 2013 17:22:06 +0000 Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAB7C77@CHAXCH01.corp.arin.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <"8DA1853CE466B041B104C1CAEE00 B3748FAB4B9A"@CHAXCH01.corp.arin.net> <184F460B-1EDB-4C84-8EFB-38643B71AAF5@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB5B60@CHAXCH01.corp.arin.net> <794B6B21-E645-4941-B7A5-C3A96274FF84@castlepoint.net> In-Reply-To: <794B6B21-E645-4941-B7A5-C3A96274FF84@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B19FF7C4971FE48AAA2FF63F6D12F01@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 17:22:43 -0000 On Apr 2, 2013, at 12:27 PM, Shane Amante wrote: > IMO, there is still one key difference. ISP's are _directly_ involved in= receiving such orders, evaluating them for validity, applicability and the= n carrying them out. This can also include providing a heads-up to operati= ons teams, in that SP, that a change in configuration to effect it was "pur= poseful", thus saving substantial time + OpEx not trying to track down a "g= eneral connectivity issue" that a customer calls in and reports to the SP. >=20 > OTOH, with the RPKI ... the actions carried out by, for example, an RIR w= ill have to be without consultation of the ISP(s) with the directly attache= d customer, in the case of sealed orders. How does the SP know that a cert= ificate was revoked due: a) a bug; b) lack of payment to their RIR; or, c) = a lawful order? And, more importantly, could/should/would ISP's act differ= ently, in terms of routing on their networks in any of those cases? That would suggest that monitoring and alerting aspects of these services=20 are indeed important, but that doesn't appear to be materially different=20 than the risks associated with relying on third-party filter lists, anti- spam blocklists, or IRR data for delivering reliable services today. /John From kent@bbn.com Tue Apr 2 10:59:12 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEEF21F8C6F for ; Tue, 2 Apr 2013 10:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcvUijJ5vkH5 for ; Tue, 2 Apr 2013 10:59:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AF18A21F8C5C for ; Tue, 2 Apr 2013 10:59:11 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50703) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UN5U7-000HRN-R6; Tue, 02 Apr 2013 13:59:03 -0400 Message-ID: <515B1C6B.5070207@bbn.com> Date: Tue, 02 Apr 2013 13:59:07 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Danny McPherson , sidr References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAB4B9A@CHAXCH01.corp.arin.net> <43525ae3fae7e3c9a5e12062c693a7ba@tcb.net> In-Reply-To: <43525ae3fae7e3c9a5e12062c693a7ba@tcb.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 17:59:12 -0000 Danny, The architecture permits overlapping allocations to accommodate transfers that involve address space that is in use. I've been told by several operators that, for this sort of transfer, such overlap is required. Steve On 4/2/13 12:02 PM, Danny McPherson wrote: > ... > As for today, the architecture permits such collisions, which I think > is the issue most agree is, err.. suboptimal. > > -danny > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From kent@bbn.com Tue Apr 2 11:08:07 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1231021F8C14 for ; Tue, 2 Apr 2013 11:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJW1Jtw9ZiqL for ; Tue, 2 Apr 2013 11:08:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5D22621F8C00 for ; Tue, 2 Apr 2013 11:08:06 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50716) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UN5cq-000Piy-9V; Tue, 02 Apr 2013 14:08:04 -0400 Message-ID: <515B1E87.7080605@bbn.com> Date: Tue, 02 Apr 2013 14:08:07 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: sidr@ietf.org, shane@castlepoint.net References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9BAD9CCC-D6C7-467C-95CF-92BA47494E78@castlepoint.net> In-Reply-To: <9BAD9CCC-D6C7-467C-95CF-92BA47494E78@castlepoint.net> Content-Type: multipart/alternative; boundary="------------020203010606070406000800" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:08:07 -0000 This is a multi-part message in MIME format. --------------020203010606070406000800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Shane, > As one operator whose worldwide routing/operations could be negatively > impacted by the above, it would be nice to have a concise statement > about what is/was the original intent of the design of the RPKI with > respect to the above. In addition, it would be useful to see if any > potential remedies/solutions may be employed (and, any associated > overhead/delays/*costs*/etc. they incur) that may be used to mitigate > them /before/ they manifest themself in the network, at which point > operators will be obligated to stop using those 'trusted information > repositories' to directly inform routing. The intent of the RPKI has always been to create a PKI that parallels the allocation hierarchy. The downside of this is that errors, or malicious actions, by orgs at higher tiers have the potential to adversely impact resource holders at lower tiers. At certain tiers in the allocation hierarchy this is true irrespective of the use of the RPKI. For example, if a targeted entity receives an PA allocation from an ISP and that ISP is forced by a LEO to suspend service for that entity, but to still advertise the sub-allocated prefix, the target has a problem. if an RIR accidentally allocated the same prefix to two different entities, there would be a problem for one or both of them when they tried to advertise the twice-allocated space. I am working on a doc, to which I alluded in my reply to Sharon last week, that examines a wide range of cases in which an organization in the allocation hierarchy makes an error, or is forced to whack an allocation. The doc describes ways that such activity can be detected, and remediation options. Steve --------------020203010606070406000800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Shane,
As one operator whose worldwide routing/operations could be negatively impacted by the above, it would be nice to have a concise statement about what is/was the original intent of the design of the RPKI with respect to the above.  In addition, it would be useful to see if any potential remedies/solutions may be employed (and, any associated overhead/delays/*costs*/etc. they incur) that may be used to mitigate them /before/ they manifest themself in the network, at which point operators will be obligated to stop using those 'trusted information repositories' to directly inform routing.
The intent of the RPKI has always been to create a PKI that parallels the allocation hierarchy. The downside of
this is that errors, or malicious actions, by orgs at higher tiers have the potential to adversely impact
resource holders at lower tiers. At certain tiers in the allocation hierarchy this is true irrespective of the
use of the RPKI. For example, if a targeted entity receives an PA allocation from an ISP and that ISP is forced
by a LEO to suspend service for that entity, but to still advertise the sub-allocated prefix, the target has
a problem. if an RIR accidentally allocated the same prefix to two different entities, there would be a problem
for one or both of them when they tried to advertise the twice-allocated space. I am working on a doc, to which
I alluded in my reply to Sharon last week, that examines a wide range of cases in which an organization
in the allocation hierarchy makes an error, or is forced to whack an allocation. The doc describes ways
that such activity can be detected, and remediation options.

Steve
--------------020203010606070406000800-- From christopher.morrow@gmail.com Tue Apr 2 11:09:53 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC9121F8D09 for ; Tue, 2 Apr 2013 11:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.931 X-Spam-Level: X-Spam-Status: No, score=-101.931 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eKYUCnxL4vz for ; Tue, 2 Apr 2013 11:09:52 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAD121F8CF8 for ; Tue, 2 Apr 2013 11:09:51 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id y8so757385lbh.7 for ; Tue, 02 Apr 2013 11:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tKdkRazyCsMxmKBUjT/SIdmriJg1bqNBgKg4Ao3PyrU=; b=Bk9zYtPFu2MTKz2A5jMea4X3hRDSX0PIIoFltIW0/vBUIEBCeIDsh8Wozz9Uo3k18F JPREnGdpg+SKlpMZUvdCqhGvklSdf1EY8PBvwbFRiEFcViZwoe5bYacaE/Q71YFjh0zg BZ7gaNQbkm9eSZQV9jmvAxMzt2vwslGXWFocaAxKAiTeQSuQV6f8m1oIG64Pb8yAL5oF i+M5JesO+lRSqtuu5CJIzKS02BV/jbOVja2yuQCbSBtJ7y9OXp3a92A6urq84iq2+/RS 7PQLJP/sposZPRHgO1PmrC5wGWpnaLD3zdsdXKppdnWEL/wppcwp1xKZqt1hJFVnACa2 VhgQ== MIME-Version: 1.0 X-Received: by 10.112.23.193 with SMTP id o1mr8165578lbf.66.1364926190997; Tue, 02 Apr 2013 11:09:50 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.112.3 with HTTP; Tue, 2 Apr 2013 11:09:50 -0700 (PDT) In-Reply-To: <515B1C6B.5070207@bbn.com> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAB4B9A@CHAXCH01.corp.arin.net> <43525ae3fae7e3c9a5e12062c693a7ba@tcb.net> <515B1C6B.5070207@bbn.com> Date: Tue, 2 Apr 2013 14:09:50 -0400 X-Google-Sender-Auth: qonVIqPY0VEM7MaZv_rig19K1jw Message-ID: From: Christopher Morrow To: Stephen Kent Content-Type: multipart/alternative; boundary=485b390f7c00c25bb204d964a413 Cc: sidr Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:09:53 -0000 --485b390f7c00c25bb204d964a413 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent wrote: > Danny, > > The architecture permits overlapping allocations to accommodate transfers > that involve address space that > is in use. I've been told by several operators that, for this sort of > transfer, such overlap > is required. > > overlap with respect to: ADDRESSBLOCK + ASN right? so initially: 128.2.35.0/24 + AS28 In the near-future as 128.2.35.0/24 moves from AS28 -> AS22224: 128.2.35.0/24 + AS28 128.2.35.0/24 + AS22224 and at some point in the further future: 128.2.35.0/24 + AS22224 (and ideally the initial ROA ends up on a CRL...) right? Enable /make before break/ for customers moving from attachment point to attachment point. -chris > Steve > On 4/2/13 12:02 PM, Danny McPherson wrote: > >> ... >> >> As for today, the architecture permits such collisions, which I think is >> the issue most agree is, err.. suboptimal. >> >> -danny >> >> ______________________________**_________________ >> 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 > --485b390f7c00c25bb204d964a413 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent <= kent@bbn.com> wrote:
Danny,

The architecture permits overlapping allocations to accommodate transfers t= hat involve address space that
is in use. I've been told by several operators that, for this sort of t= ransfer, such overlap
is required.


overlap with respect to:
=A0 = ADDRESSBLOCK + ASN

right? so initially= :
=A0 128.2.35.0/24 + AS28

In the near-future as 128.2.35.0/24 moves from AS28 -> AS22224:
=A0 128.2.35.0/24 + AS28
=A0 128.2.35.0/24 + AS22224

and at some point in the further future:=A0 128.2.35.0/24 + AS22224

(and ideally the initial ROA ends up on a CRL..= .)

right? Enable /make before break/ for custo= mers moving from attachment point to attachment point.

=
-chris
=A0
Steve
On 4/2/13 12:02 PM, Danny McPherson wrote:
...

As for today, the architecture permits such collisions, which I think is th= e issue most agree is, err.. suboptimal.

-danny

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


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

--485b390f7c00c25bb204d964a413-- From kent@bbn.com Tue Apr 2 11:11:34 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0905021F8D14 for ; Tue, 2 Apr 2013 11:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mlmjbags941 for ; Tue, 2 Apr 2013 11:11:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 765E121F8D09 for ; Tue, 2 Apr 2013 11:11:33 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50719) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UN5gC-000Hmi-C3; Tue, 02 Apr 2013 14:11:32 -0400 Message-ID: <515B1F57.200@bbn.com> Date: Tue, 02 Apr 2013 14:11:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: sidr@ietf.org, shane@castlepoint.net References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00 B3748FAB4B9A@CHAXCH01.corp.arin.net> <184F460B-1EDB-4C84-8EFB-38643B71AAF5@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB5B60@CHAXCH01.corp.arin.net> <794B6B21-E645-4941-B7A5-C3A96274FF84@castlepoint.net> In-Reply-To: <794B6B21-E645-4941-B7A5-C3A96274FF84@castlepoint.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:11:34 -0000 Shane, > IMO, there is still one key difference. ISP's are _directly_ involved in receiving such orders, evaluating them for validity, applicability and then carrying them out. This can also include providing a heads-up to operations teams, in that SP, that a change in configuration to effect it was "purposeful", thus saving substantial time + OpEx not trying to track down a "general connectivity issue" that a customer calls in and reports to the SP. > > OTOH, with the RPKI ... the actions carried out by, for example, an RIR will have to be without consultation of the ISP(s) with the directly attached customer, in the case of sealed orders. How does the SP know that a certificate was revoked due: a) a bug; b) lack of payment to their RIR; or, c) a lawful order? And, more importantly, could/should/would ISP's act differently, in terms of routing on their networks in any of those cases? As I mentioned in my message to Sharon last week, each resource holder can detect any action by any party that renders ROAs for the resource holder invalid. This sort of self-monitoring can be performed as a side effect of normal RPKI processing. The next step is for the affected party to notify other ISPs of the action, which, I suspect, can be done in a variety of ways. How ISPs cosoe to use this info is still a local decision, as it is today. > It's one thing for an operator to have direct influence/knowledge re: actions it takes on their own network, it's another matter entirely when third-parties have that control over your operations, particularly without any recourse. I don't think the RPKI results in the change you suggest above. It is still up to each ISP to decide how to make use of the data acquired via the RPKI. The LTAM mechanism provides a specific way for an ISP to override most of the sorts of changes that have been described. For example, if a country elects to maintain RPKI data for ISPs that operate there (exclusively), the country could publish a contsriants file in the LTAM-specified format, as a way of "protecting" the resources for these ISPs. Other ISPs, outside of the country, can elect to make use of this data if they worry that an LEO outside of the geopolitical jurisdiction tries to use the RPKI to whack resources within the country. In the end, it is still up to each ISP to decide how to make use of RPKI data. Steve From kent@bbn.com Tue Apr 2 11:43:45 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E4B21F8BA1 for ; Tue, 2 Apr 2013 11:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc0tsKwed4ws for ; Tue, 2 Apr 2013 11:43:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 37C6021F8C00 for ; Tue, 2 Apr 2013 11:43:37 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50724) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UN6BB-0000EF-Fl; Tue, 02 Apr 2013 14:43:33 -0400 Message-ID: <515B26D5.8000708@bbn.com> Date: Tue, 02 Apr 2013 14:43:33 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Sharon Goldberg References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dannyc@bu.edu, broglek@bu.edu, eth3rs@gmail.com, sidr@ietf.org Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:43:45 -0000 Sharon, ... > > > Nonetheless, all of the methods for whacking a ROA described in the > paper > > are detectable by anyone who monitors the RPKI. One might argue that > each > > resource holder should monitor his/her RPKI pub point to detect any > action > > that causes one's ROA to become unverifiable. > > We agree that monitoring is important and in fact we are working on > such a monitor right now. > Great. I think we'll include this feature in future RPSRIR releases too. The important point, IMHO, is that this sort of monitoring is easiest if performed by resource holders themselves. > > > Also, the scenario addressed in 2.2.1 > > is specific to a very narrowly-defined class of resource holders who > elected the third of > > three approaches (not the preferred approach) to participating in > the RPKI. > > To clarify, which 3 approaches do you mean? > In 7.3.2 of RFC 6480 the two RECOMMENDED approaches are for a subscriber to receive a CA cert from the ISP from which the address space allocation was received, or for the subscriber to have the ISP that is the allocation source issue a ROA for the subscriber. I consider the second one to be less preferred than the first. the third approach applies only if the subscriber does not have it's own ASN, and that approach is NOT RECOMMENDED. I misspoke when I said that your analysis, in 2.2.1 focused on the third of three approaches applicable in this case. You looked at the second of three, and the third approach is no applicable because you did assume that the subscriber had it's own ASN. > > In 2.2.1 we consider an org B who has its own ASN but chooses not to > have its own resource cert; instead, it has org A issue its ROA. > (This is one of two recommendations in RFC6480 Section 7.3.2 first > paragraph.) In this case, the parent org A can whack org B's ROA in > surreptitious ways, without explicitly using revocation lists. > Yes, the ROA can be whacked this way. > > In the case where org B has its own resource cert, ROA whacking is > more detectable, because it might involve issuing new ROA, > grandparenting, etc. We discuss that in Sections 2.2.2-2.2.3, 2.3-2.5. > I believe that ROA whacking is always detectable by the whackee. It's harder for 3rd parties to detect, because there might be legitimate reasons for other actions. I suggest that we not consider grand parenting in this discussion. There is no RFC that allows grand parenting. More importantly it runs counter to the CP and the architecture, which call for entities acting as CA to issue certs based on the databases that they operate to track the allocations that they made. > We are particularly curious about how legal recourse would play out in > cases where the targeted party is in a different country than the > party that whacked its ROA. For example, what if an American > organization whacks a ROA for an AS in a different country (or vice > versa)? > > We did some analysis of when a subject in one country can whack a ROA > for an AS in another country. See the heatmaps on slide 10-11 of the > slide deck: > > http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf > > > To get these, we took data on the direct-allocations from each RIR, > and then used routeviews and RIPE RIS data to determine for each > directly-allocated prefix, how many different ASes originate the > prefix or any of its subprefixes. We show this in slide 10. To get > slide 11, we then use the AS-to-country mappings provided by the RIRs > to determine the number of countries that have ASes who originate > prefixes that are covered by the directly allocated prefix. (Note we > are in the midst of writing up a full report of these results, that > I'll share with the list in a month or two.) > So, if we suppose that prefixes directly allocated by the RIRs are > given their own resource certs, we see that these resource certs can > whack ROAs for ASes in multiple countries. (Look at 8/8 or 12/8, for > example.) How would takedowns play out if they cross national borders? It is often possible for a ROA representing resources in country X to be whacked by an org in country Z, because the allocation hierarchy is not aligned along country boundaries, and because some ISPs operate across country boundaries. One way to mitigate these concerns, if they become significant, is for a country to operate a service where it tracks allocations to ISPs that operate within its borders. It can publish an LTAM constraints file that tracks the allocations, and ISPs that wish to check that file against data returned by the RPKI repository system can use this mechanism to detect anomalies. ISPs can then decide which source to believe. I know of one country that is already considering this model. It is not clear whether many countries will decide that this approach is worth the effort. Another way to tackle the LEO-based aspect of this concern is to persuade LEOs to not view ROA whacking as a good tool. I've had this discussion with FBI cyber crime folks. I also note that there is an ongoing IAB effort to produce a position statement on the broader topic (encompassing both the DNS and the RPKI). Steve From kent@bbn.com Tue Apr 2 11:45:40 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B2921F8CEC for ; Tue, 2 Apr 2013 11:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj2Uka8NjiZO for ; Tue, 2 Apr 2013 11:45:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6405821F8CD2 for ; Tue, 2 Apr 2013 11:45:39 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50726) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UN6DA-0000FW-4x; Tue, 02 Apr 2013 14:45:36 -0400 Message-ID: <515B274F.4020602@bbn.com> Date: Tue, 02 Apr 2013 14:45:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Christopher Morrow References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAB4B9A@CHAXCH01.corp.arin.net> <43525ae3fae7e3c9a5e12062c693a7ba@tcb.net> <515B1C6B.5070207@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050303000306070309000500" Cc: sidr Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:45:40 -0000 This is a multi-part message in MIME format. --------------050303000306070309000500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Chris, Yes, the example you provided matches what I had in mind. Steve - > On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent > wrote: > > Danny, > > The architecture permits overlapping allocations to accommodate > transfers that involve address space that > is in use. I've been told by several operators that, for this sort > of transfer, such overlap > is required. > > > overlap with respect to: > ADDRESSBLOCK + ASN > > right? so initially: > 128.2.35.0/24 + AS28 > > In the near-future as 128.2.35.0/24 moves from > AS28 -> AS22224: > 128.2.35.0/24 + AS28 > 128.2.35.0/24 + AS22224 > > and at some point in the further future: > 128.2.35.0/24 + AS22224 > > (and ideally the initial ROA ends up on a CRL...) > > right? Enable /make before break/ for customers moving from attachment > point to attachment point. > > -chris > > Steve > On 4/2/13 12:02 PM, Danny McPherson wrote: > > ... > > As for today, the architecture permits such collisions, which > I think is the issue most agree is, err.. suboptimal. > > -danny > > _______________________________________________ > 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 > > --------------050303000306070309000500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Chris,

Yes, the example you provided matches what I had in mind.

Steve
-

On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent <kent@bbn.com> wrote:
Danny,

The architecture permits overlapping allocations to accommodate transfers that involve address space that
is in use. I've been told by several operators that, for this sort of transfer, such overlap
is required.


overlap with respect to:
  ADDRESSBLOCK + ASN

right? so initially:
  128.2.35.0/24 + AS28

In the near-future as 128.2.35.0/24 moves from AS28 -> AS22224:
  128.2.35.0/24 + AS28
  128.2.35.0/24 + AS22224

and at some point in the further future:
  128.2.35.0/24 + AS22224

(and ideally the initial ROA ends up on a CRL...)

right? Enable /make before break/ for customers moving from attachment point to attachment point.

-chris
 
Steve
On 4/2/13 12:02 PM, Danny McPherson wrote:
...

As for today, the architecture permits such collisions, which I think is the issue most agree is, err.. suboptimal.

-danny

_______________________________________________
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


--------------050303000306070309000500-- From shane@castlepoint.net Tue Apr 2 11:59:49 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A64721F8BC5 for ; Tue, 2 Apr 2013 11:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpXynrM7o25V for ; Tue, 2 Apr 2013 11:59:49 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2162821F8BBB for ; Tue, 2 Apr 2013 11:59:48 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 35C15300054 for ; Tue, 2 Apr 2013 18:59:48 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id A789B300027; Tue, 2 Apr 2013 12:59:47 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAB7C77@CHAXCH01.corp.arin.net> Date: Tue, 2 Apr 2013 12:59:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6B544509-E267-4319-8532-50A3870D163C@castlepoint.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <"8DA1853CE466B041B104C1CAEE0 0 B3748FAB4B9A"@CHAXCH01.corp.arin.net> <184F460B-1EDB-4C84-8EFB-38643B71AAF5@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB5B60@CHAXCH01.corp.arin.net> <794B6B21-E645-4941-B7A5-C3A96274FF84@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB7C77@CHAXCH01.corp.arin.net> To: John Curran X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Apr 2 12:59:48 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 515b2aa442077203417612 X-DSPAM-Factors: 27, 2013+at, 0.01000, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, that+are, 0.01000, to+#+#+in, 0.01000, the+#+#+#+by, 0.01000, On+Apr, 0.01000, On+Apr, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, Mime-Version*OS+X, 0.01000, and+or, 0.01000, is+that, 0.01000, 2+#+at, 0.01000, 2+#+at, 0.01000, and+then, 0.01000, in+#+#+#+it, 0.01000, From*Amante+shane, 0.01000, 2+2013, 0.01000, 2+2013, 0.01000, for+that, 0.01000, be+#+#+#+the, 0.01000, be+#+#+#+the, 0.01000, the+#+#+the, 0.01000, the+#+#+the, 0.01000, Cc*ietf.org+#+#+ietf.org, 0.01000, Subject*sidr+#+University, 0.01000, at+#+#+PM, 0.01000 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:59:49 -0000 John, On Apr 2, 2013, at 11:22 AM, John Curran wrote: > On Apr 2, 2013, at 12:27 PM, Shane Amante = wrote: >> IMO, there is still one key difference. ISP's are _directly_ = involved in receiving such orders, evaluating them for validity, = applicability and then carrying them out. This can also include = providing a heads-up to operations teams, in that SP, that a change in = configuration to effect it was "purposeful", thus saving substantial = time + OpEx not trying to track down a "general connectivity issue" that = a customer calls in and reports to the SP. >>=20 >> OTOH, with the RPKI ... the actions carried out by, for example, an = RIR will have to be without consultation of the ISP(s) with the directly = attached customer, in the case of sealed orders. How does the SP know = that a certificate was revoked due: a) a bug; b) lack of payment to = their RIR; or, c) a lawful order? And, more importantly, = could/should/would ISP's act differently, in terms of routing on their = networks in any of those cases? >=20 > That would suggest that monitoring and alerting aspects of these = services=20 > are indeed important, but that doesn't appear to be materially = different=20 > than the risks associated with relying on third-party filter lists, = anti- > spam blocklists, or IRR data for delivering reliable services today. In today's world, if a resource holder doesn't "like" the services = provided by an IRR (perhaps, the IRR is unreliable, not cost-effective, = etc.), then there's very low-bar for that resource-holder to register = their resources in one or more third-party IRR's they consider "better", = for some value of better. I think we would agree that the advantage = here is a resource-holder gets to "shop around" for Routing Registry = Services based on what attributes in a registry the resource holder = considers important, (price, availability, susceptibility to LEA), etc. = The one, not insignificant, downside is that those (third-party) = registries do not, at the moment, provide rigorous authentication of the = resources that are registered, (but clearly that's a known risk that = exists and is "accepted" today -- whether that continues to be true = and/or less acceptable in the future is clearly unknown). So, in the future of the RPKI, as a resource holder, how am I able to = "shop around" as per the above, to mitigate one or more of the concerns = that I've illustrated above? Hint: given the, at present, limited = number of RIR's near the top of the allocation hierarchy, there would = appear to be little choice. -shane= From danny@tcb.net Tue Apr 2 12:20:20 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C99E21F8D6A for ; Tue, 2 Apr 2013 12:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.251 X-Spam-Level: X-Spam-Status: No, score=-100.251 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C09rB2hfH4Km for ; Tue, 2 Apr 2013 12:20:19 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id E429421F8D3C for ; Tue, 2 Apr 2013 12:20:19 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id AB63E300054 for ; Tue, 2 Apr 2013 19:20:19 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.friendswithtools.org (Postfix) with ESMTP id 48EA3300027; Tue, 2 Apr 2013 13:20:18 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Apr 2013 13:20:18 -0600 From: Danny McPherson To: Stephen Kent In-Reply-To: <515B1C6B.5070207@bbn.com> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAB4B9A@CHAXCH01.corp.arin.net> <43525ae3fae7e3c9a5e12062c693a7ba@tcb.net> <515B1C6B.5070207@bbn.com> Message-ID: <2d9950c43a1ec5de444d7f299f144966@tcb.net> X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Apr 2 13:20:19 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 515b2f7342071524062453 X-DSPAM-Factors: 27, 2013+#+02, 0.01000, Stephen+Kent, 0.01000, To*Kent+#+bbn.com, 0.01000, To*Kent+kent, 0.01000, Subject*sidr+#+University, 0.01000, Subject*Princeton+#+#+IP, 0.01000, Subject*IP+#+Reachability, 0.01000, On+#+04, 0.01000, Subject*Impacting+#+#+Reachability, 0.01000, To*Stephen+#+kent, 0.01000, Subject*RPKI+Manipulations, 0.01000, Subject*University+#+#+Address, 0.01000, Subject*Princeton+#+#+#+Address, 0.01000, to+the, 0.01000, Subject*sidr+#+#+#+IP, 0.01000, Subject*University+Impacting, 0.01000, that+#+#+#+that, 0.01000, Subject*via+#+Manipulations, 0.01000, 2013+04, 0.01000, Kent+wrote, 0.01000, the+#+#+#+as, 0.01000, From*Danny+#+danny, 0.01000, Subject*Princeton+#+Impacting, 0.01000, From*Danny+#+#+tcb.net, 0.01000, On+#+#+02, 0.01000, Subject*sidr+#+#+Impacting, 0.01000, Subject*Re+#+#+University, 0.01000 Cc: sidr Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 19:20:20 -0000 On 2013-04-02 11:59, Stephen Kent wrote: > Danny, > > The architecture permits overlapping allocations to accommodate > transfers that involve address space that > is in use. I've been told by several operators that, for this sort of > transfer, such overlap is required. Yes, I understand that. I was referring to the multi-root TA, as I suspect you were aware. -danny From kent@bbn.com Tue Apr 2 12:47:48 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FEB21F8EB5 for ; Tue, 2 Apr 2013 12:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEwUpF8kyh99 for ; Tue, 2 Apr 2013 12:47:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4C51021F8E7D for ; Tue, 2 Apr 2013 12:47:47 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50783) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UN7BH-000KGV-J1; Tue, 02 Apr 2013 15:47:43 -0400 Message-ID: <515B35DF.3080708@bbn.com> Date: Tue, 02 Apr 2013 15:47:43 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Danny McPherson References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAB4B9A@CHAXCH01.corp.arin.net> <43525ae3fae7e3c9a5e12062c693a7ba@tcb.net> <515B1C6B.5070207@bbn.com> <2d9950c43a1ec5de444d7f299f144966@tcb.net> In-Reply-To: <2d9950c43a1ec5de444d7f299f144966@tcb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 19:47:48 -0000 Danny, No, I didn't realize you were referring to the current multi-TA environment. I thought that John Curran was alluding to plans to create an ICANN-managed "global TA", which is why I didn't realize the context you had in mind. Steve ------ On 4/2/13 3:20 PM, Danny McPherson wrote: > On 2013-04-02 11:59, Stephen Kent wrote: >> Danny, >> >> The architecture permits overlapping allocations to accommodate >> transfers that involve address space that >> is in use. I've been told by several operators that, for this sort of >> transfer, such overlap is required. > > Yes, I understand that. > > I was referring to the multi-root TA, as I suspect you were aware. > > -danny > > > > From jcurran@arin.net Tue Apr 2 13:46:18 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD3821F8D28 for ; Tue, 2 Apr 2013 13:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[AWL=3.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AhxkTMyxDBF for ; Tue, 2 Apr 2013 13:46:17 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6EB21F8CF7 for ; Tue, 2 Apr 2013 13:46:17 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id E17D716523B; Tue, 2 Apr 2013 16:45:30 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 42AFD165230; Tue, 2 Apr 2013 16:45:28 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 2 Apr 2013 16:45:13 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 2 Apr 2013 16:45:22 -0400 From: John Curran To: Shane Amante Thread-Topic: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations Thread-Index: AQHOLxi7J8r/o/vLLEebRqd2la6FBJjDjVsAgAAdgQA= Date: Tue, 2 Apr 2013 20:45:21 +0000 Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAB97A0@CHAXCH01.corp.arin.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <"8DA1853CE466B041B104C1CAEE0 0 B3748FAB4B9A"@CHAXCH01.corp.arin.net> <184F460B-1EDB-4C84-8EFB-38643B71AAF5@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB5B60@CHAXCH01.corp.arin.net> <794B6B21-E645-4941-B7A5-C3A96274FF84@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB7C77@CHAXCH01.corp.arin.net> <6B544509-E267-4319-8532-50A3870D163C@castlepoint.net> In-Reply-To: <6B544509-E267-4319-8532-50A3870D163C@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <25F0A38CBBAD00489ECDA0316EA86716@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 20:46:18 -0000 On Apr 2, 2013, at 2:59 PM, Shane Amante wrote: > So, in the future of the RPKI, as a resource holder, how am I able to "sh= op around" as per the above, to mitigate one or more of the concerns that I= 've illustrated above? Hint: given the, at present, limited number of RIR's= near the top of the allocation hierarchy, there would appear to be little = choice. I'm not certain you are describing a problem in RPKI architecture for=20 the working group: while there is ability to have overlap in RPKI=20 (as noted for purposes such as transfers and moves), there are still assumptions regarding regions and hierarchy in the Internet Registry=20 system that make your perceived problem difficult to solve in the=20 general case. One approach (if it were really an issue) would be to=20 handle it similar to the DNS with shared registry/multiple registrars (and the registrars providing the RPKI services you seek), but that=20 would not likely be a sidr (or IETF) scope work item in any case... /John From shane@castlepoint.net Tue Apr 2 14:59:12 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B0321F8A40 for ; Tue, 2 Apr 2013 14:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3z6bqMyEolT for ; Tue, 2 Apr 2013 14:59:12 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6A17921F8A3F for ; Tue, 2 Apr 2013 14:59:11 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 9BC1B30007E for ; Tue, 2 Apr 2013 21:59:11 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 19C21300028; Tue, 2 Apr 2013 15:59:11 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAB97A0@CHAXCH01.corp.arin.net> Date: Tue, 2 Apr 2013 15:59:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <"8DA1853CE466B041B104C1CAEE0 0 B3748FAB4B9A"@CHAXCH01.corp.arin.net> <184F460B-1EDB-4C84-8EFB-38643B71AAF5@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB5B60@CHAXCH01.corp.arin.net> <794B6B21-E645-4941-B7A5-C3A96274FF84@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB7C77@CHAXCH01.corp.arin.net> <6B544509-E267-4319-8532-50A3870D163C@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB97A0@CHAXCH01.corp.arin.net> To: John Curran X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Apr 2 15:59:11 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 515b54af42079562576714 X-DSPAM-Factors: 27, 2013+at, 0.01000, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+to, 0.01000, and+#+#+#+the, 0.01000, to+#+#+in, 0.01000, On+Apr, 0.01000, On+Apr, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, Mime-Version*OS+X, 0.01000, and+or, 0.01000, 2+#+at, 0.01000, 2+#+at, 0.01000, and+#+#+#+to, 0.01000, From*Amante+shane, 0.01000, 2+2013, 0.01000, 2+2013, 0.01000, in+#+case, 0.01000, wrote+#+Apr, 0.01000, and+the, 0.01000, the+#+#+the, 0.01000, the+#+#+the, 0.01000, Cc*ietf.org+#+#+ietf.org, 0.01000, Subject*sidr+#+University, 0.01000, at+#+#+PM, 0.01000, at+#+#+PM, 0.01000, On+#+2, 0.01000 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:59:13 -0000 On Apr 2, 2013, at 2:45 PM, John Curran wrote: > On Apr 2, 2013, at 2:59 PM, Shane Amante = wrote: >=20 >> So, in the future of the RPKI, as a resource holder, how am I able to = "shop around" as per the above, to mitigate one or more of the concerns = that I've illustrated above? Hint: given the, at present, limited number = of RIR's near the top of the allocation hierarchy, there would appear to = be little choice. >=20 > I'm not certain you are describing a problem in RPKI architecture for=20= > the working group: while there is ability to have overlap in RPKI=20 > (as noted for purposes such as transfers and moves), there are still > assumptions regarding regions and hierarchy in the Internet Registry=20= > system that make your perceived problem difficult to solve in the=20 > general case. =20 Given the RPKI architecture has been based around the "assumptions" you = quote above and, to my knowledge, no one has questioned/challenged those = assumptions, you may be right. But, if not now, when? > One approach (if it were really an issue) would be to=20 > handle it similar to the DNS with shared registry/multiple registrars > (and the registrars providing the RPKI services you seek), but that=20 > would not likely be a sidr (or IETF) scope work item in any case... Although, if the registry function remains "constrained", as it is = today, then I'm not sure that meaningfully solves any concerns, given = that function still remains an attractive 'target' for outside parties = to (try to) exert pressure and/or operational problems to manifest = themself with the potential for very noticeable and widespread impacts. -shane= From jcurran@arin.net Tue Apr 2 18:50:04 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70F121F874B for ; Tue, 2 Apr 2013 18:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=2.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhFSSFYe1BHU for ; Tue, 2 Apr 2013 18:50:01 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id E76B221F8763 for ; Tue, 2 Apr 2013 18:49:57 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 9C9F91659CC; Tue, 2 Apr 2013 21:49:27 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 1CA071659CA; Tue, 2 Apr 2013 21:49:23 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 2 Apr 2013 21:48:42 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Tue, 2 Apr 2013 21:49:22 -0400 From: John Curran To: Shane Amante Thread-Topic: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations Thread-Index: AQHOLxi7J8r/o/vLLEebRqd2la6FBJjDjVsAgAAdgQCAABSeAIAAQFEA Date: Wed, 3 Apr 2013 01:49:21 +0000 Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FABB3D3@CHAXCH01.corp.arin.net> References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9939744e41b31c2cefcbbb83a1eb39c5@tcb.net> <8DA1853CE466B041B104C1CAEE00B3748FAAE3C7@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAAF474@CHAXCH01.corp.arin.net> <"8DA1853CE466B041B104C1CAEE0 0 B3748FAB4B9A"@CHAXCH01.corp.arin.net> <184F460B-1EDB-4C84-8EFB-38643B71AAF5@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB5B60@CHAXCH01.corp.arin.net> <794B6B21-E645-4941-B7A5-C3A96274FF84@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB7C77@CHAXCH01.corp.arin.net> <6B544509-E267-4319-8532-50A3870D163C@castlepoint.net> <8DA1853CE466B041B104C1CAEE00B3748FAB97A0@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <345B73CAE045A94E8C6F03D1D63D651A@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 01:50:04 -0000 On Apr 2, 2013, at 5:59 PM, Shane Amante wrote: > Although, if the registry function remains "constrained", as it is today,= then I'm not sure that meaningfully solves any concerns, given that functi= on still remains an attractive 'target' for outside parties to (try to) exe= rt pressure and/or operational problems to manifest themself with the poten= tial for very noticeable and widespread impacts. With the net result being that those who share those concerns are likely t decide not to make use of it and continue as today,=20 and those who are worried more about the possibility of easy=20 route hijacking will use it... (like many other security-related=20 capabilities in the Internet, the deployment choice is left to=20 each network.) /John From shane@castlepoint.net Tue Apr 2 19:25:49 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3424121F8820 for ; Tue, 2 Apr 2013 19:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHzDPF0wflbe for ; Tue, 2 Apr 2013 19:25:39 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id E3D7C21F881C for ; Tue, 2 Apr 2013 19:25:38 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 9631F300083 for ; Wed, 3 Apr 2013 02:25:38 +0000 (UTC) Received: from mbp.castlepoint.net (184-96-123-182.hlrn.qwest.net [184.96.123.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id B5221300079; Tue, 2 Apr 2013 20:25:37 -0600 (MDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BDC9D16A-77CF-42E6-99F6-FD4D9F022DE3" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <515B1E87.7080605@bbn.com> Date: Tue, 2 Apr 2013 20:25:36 -0600 Message-Id: References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9BAD9CCC-D6C7-467C-95CF-92BA47494E78@castlepoint.net> <515B1E87.7080605@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Apr 2 20:25:38 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 515b932242071577210852 X-DSPAM-Factors: 27, 2013+at, 0.01000, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+or, 0.01000, to+#+#+#+or, 0.01000, to+#+#+#+to, 0.01000, to+#+#+#+to, 0.01000, and+#+#+#+the, 0.01000, and+#+#+#+the, 0.01000, have+#+#+#+the, 0.01000, have+#+#+#+the, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, On+Apr, 0.01000, On+Apr, 0.01000, Mime-Version*OS+X, 0.01000, and+or, 0.01000, and+or, 0.01000, is+that, 0.01000, is+that, 0.01000, 2+#+at, 0.01000, 2+#+at, 0.01000, to+#+this, 0.01000, to+#+this, 0.01000, of+#+#+#+that, 0.01000, of+#+#+#+that, 0.01000, Stephen+Kent, 0.01000 Cc: sidr@ietf.org Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 02:25:49 -0000 --Apple-Mail=_BDC9D16A-77CF-42E6-99F6-FD4D9F022DE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Steve, Thanks for your response. Please see below. On Apr 2, 2013, at 12:08 PM, Stephen Kent wrote: > Shane, >> As one operator whose worldwide routing/operations could be = negatively impacted by the above, it would be nice to have a concise = statement about what is/was the original intent of the design of the = RPKI with respect to the above. In addition, it would be useful to see = if any potential remedies/solutions may be employed (and, any associated = overhead/delays/*costs*/etc. they incur) that may be used to mitigate = them /before/ they manifest themself in the network, at which point = operators will be obligated to stop using those 'trusted information = repositories' to directly inform routing. > The intent of the RPKI has always been to create a PKI that parallels = the allocation hierarchy. The downside of > this is that errors, or malicious actions, by orgs at higher tiers = have the potential to adversely impact > resource holders at lower tiers. At certain tiers in the allocation = hierarchy this is true irrespective of the > use of the RPKI. For example, if a targeted entity receives an PA = allocation from an ISP and that ISP is forced > by a LEO to suspend service for that entity, but to still advertise = the sub-allocated prefix, the target has > a problem. That is true. However, I feel the need to point a subtle, yet important = difference from today's environment. First, today, the ISP has direct knowledge prior to this 'event' = occurring and given the direct contractual relationship they have with = the customer the ISP would (IMO) be more likely to have a significant = business interest (i.e.: get paid) to ensure the order was valid, = applicable, etc. /before/ it was carried out. IOW, if the ISP is not = providing service to the customer, then the ISP may be unable to bill = for all or part of that service provided, (one, simple example: = usage-based billing). OTOH, if a third-party (RIR?) higher up the = allocation hierarchy were to "whack" a cert, thus making a cert for a = resource invalid can the same be said? Second, consider the 'scope' of where such a change will be propagated = and a time-to-restore back to "normalcy" after the matter is rectified. = Today -- for better or worse -- it's the immediate upstream ISP(s) of = the targeted entity that, in your example, would be curtailing the = propagation of routes and/or forwarding to the 'targeted entity' to/from = the rest of the Internet. IOW, if (or, when) the matter is = appropriately resolved, then (I suspect) the restoration times to get = the customer back online are minimal today given we are largely talking = about BGP propagation times, i.e.: likely minutes. Ultimately, it's = just those immediate upstream ISP's that need to 'act' in order to = propagate that route to the entire Internet. OTOH, in a fully = RPKI-enabled world, SP's the world over are performing origin filtering = using information from the RPKI at all of their customer and peering = interconnections ... this could make for some rather long 'restoration' = times for the 'targeted entity' based on several of the models I've seen = tossed around in SIDR. And, the longer the restoration times, again, = the more noticeable the impact it could have on the ISP's who provide = service to/from the 'targeted entity', (again: usage-based billing). Nonetheless, I will be interested to see if the paper you are writing = will include these types of detail. > if an RIR accidentally allocated the same prefix to two different = entities, there would be a problem > for one or both of them when they tried to advertise the = twice-allocated space. While theoretically a possibility, I'd be curious to know if the above = is a common occurrence? If the RIR were concerned about this, one quick = way to ensure this did not happen would be for the RIR to consult a = "live" routing table to see if the space they are (re-)allocating is = already being announced somewhere. In fact, I'd be surprised if they = did not do this already. (Granted, this does not prevent the same space = from ever being twice allocated, because the first allocation was = sitting dormant/not-announced at that moment). > I am working on a doc, to which > I alluded in my reply to Sharon last week, that examines a wide range = of cases in which an organization > in the allocation hierarchy makes an error, or is forced to whack an = allocation. The doc describes ways > that such activity can be detected, and remediation options. I look forward to reading that document when it's published. -shane= --Apple-Mail=_BDC9D16A-77CF-42E6-99F6-FD4D9F022DE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 kent@bbn.com> = wrote:
=20 =20
Shane,
As one operator whose worldwide routing/operations could be negatively impacted by the above, it would be nice to have a concise statement about what is/was the original intent of the design of the RPKI with respect to the above.  In addition, = it would be useful to see if any potential remedies/solutions may be employed (and, any associated overhead/delays/*costs*/etc. they incur) that may be used to mitigate them /before/ they manifest themself in the network, at which point operators will be obligated to stop using those 'trusted information repositories' to directly inform routing.
The intent of the RPKI has always been to create a PKI that parallels the allocation hierarchy. The downside of
this is that errors, or malicious actions, by orgs at higher tiers have the potential to adversely impact
resource holders at lower tiers. At certain tiers in the allocation hierarchy this is true irrespective of the
use of the RPKI. For example, if a targeted entity receives an PA allocation from an ISP and that ISP is forced
by a LEO to suspend service for that entity, but to still advertise the sub-allocated prefix, the target has
a problem.

That is true. =  However, I feel the need to point a subtle, yet important = difference from today's environment.

First, = today, the ISP has direct knowledge prior to this 'event' occurring = and given the direct contractual relationship they have with the = customer the ISP would (IMO) be more likely to have a significant = business interest (i.e.: get paid) to ensure the order was valid, = applicable, etc. /before/ it was carried out.  IOW, if the ISP is = not providing service to the customer, then the ISP may be unable to = bill for all or part of that service provided, (one, simple example: = usage-based billing).  OTOH, if a third-party (RIR?) higher up the = allocation hierarchy were to "whack" a cert, thus making a cert for a = resource invalid can the same be said?

Second, = consider the 'scope' of where such a change will be propagated and a = time-to-restore back to "normalcy" after the matter is rectified. =  Today -- for better or worse -- it's the immediate upstream = ISP(s) of the targeted entity that, in your example, would be curtailing = the propagation of routes and/or forwarding to the 'targeted entity' = to/from the rest of the Internet.  IOW, if (or, when) the matter is = appropriately resolved, then (I suspect) the restoration times to get = the customer back online are minimal today given we are largely talking = about BGP propagation times, i.e.: likely minutes.  Ultimately, = it's just those immediate upstream ISP's that need to 'act' in order to = propagate that route to the entire Internet.  OTOH, in a fully = RPKI-enabled world, SP's the world over are performing origin filtering = using information from the RPKI at all of their customer and peering = interconnections ... this could make for some rather long 'restoration' = times for the 'targeted entity' based on several of the models I've seen = tossed around in SIDR.  And, the longer the restoration times, = again, the more noticeable the impact it could have on the ISP's who = provide service to/from the 'targeted entity', (again: usage-based = billing).

Nonetheless, I will be interested to = see if the paper you are writing will include these types of = detail.


if an RIR accidentally allocated = the same prefix to two different entities, there would be a problem
for one or both of them when they tried to advertise the twice-allocated space.

While = theoretically a possibility, I'd be curious to know if the above is a = common occurrence?  If the RIR were concerned about this, one quick = way to ensure this did not happen would be for the RIR to consult a = "live" routing table to see if the space they are (re-)allocating is = already being announced somewhere.  In fact, I'd be surprised if = they did not do this already.  (Granted, this does not prevent the = same space from ever being twice allocated, because the first allocation = was sitting dormant/not-announced at that = moment).


I am working on a doc, to which
I alluded in my reply to Sharon last week, that examines a wide range of cases in which an organization
in the allocation hierarchy makes an error, or is forced to whack an allocation. The doc describes ways
that such activity can be detected, and remediation = options.

I look forward to = reading that document when it's = published.

-shane
= --Apple-Mail=_BDC9D16A-77CF-42E6-99F6-FD4D9F022DE3-- From christopher.morrow@gmail.com Tue Apr 2 19:31:31 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F85721E8041 for ; Tue, 2 Apr 2013 19:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.764 X-Spam-Level: X-Spam-Status: No, score=-102.764 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml+aAwofoPQu for ; Tue, 2 Apr 2013 19:31:30 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id D916921E8040 for ; Tue, 2 Apr 2013 19:31:29 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id t11so1103101lbi.39 for ; Tue, 02 Apr 2013 19:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=T+2PhTV2EFDqLzkLB+166SRSxDKqXWv43Iibh3WKHz0=; b=y8tm0hRwIZxgTdwkI2OmBItkeGIHDY0pJkol2D13L67CqcGiEddX3NQMcIKve90Lvc wRe9hFZzWrET5L8BvIiswCGa99HH2mOokEHe+1cDUDSVPufjb5fmfNkg7J0EtFHQ0UXN K1K/q3SMFlX4ZAVWsc7NJFmccUewEnSb69LBhXQB/bLSJYhI83DRMZ2MjDCuoVyzzR6s V1q9wyamkaxknC9QvkcBt0CyqdPqW3FG68zAn7I2lksHqXdJzOXyL3hS3BaXyDHEfW2l DR3sKtalFi7MKhhIOL00xCBGvf854TkJqcSOnUBzdncYGTRVtnAgZH5lr+94wJDCeOsl WEFQ== MIME-Version: 1.0 X-Received: by 10.152.145.134 with SMTP id su6mr9028987lab.35.1364956288819; Tue, 02 Apr 2013 19:31:28 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.112.3 with HTTP; Tue, 2 Apr 2013 19:31:28 -0700 (PDT) In-Reply-To: References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9BAD9CCC-D6C7-467C-95CF-92BA47494E78@castlepoint.net> <515B1E87.7080605@bbn.com> Date: Tue, 2 Apr 2013 22:31:28 -0400 X-Google-Sender-Auth: -BAyzq5RJB9D6H1VSoImIUSCHd4 Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: multipart/alternative; boundary=e89a8f234659baabea04d96ba6c8 Cc: "sidr@ietf.org" Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 02:31:31 -0000 --e89a8f234659baabea04d96ba6c8 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 2, 2013 at 10:25 PM, Shane Amante wrote: > IOW, if (or, when) the matter is appropriately resolved, then (I suspect) > the restoration times to get the customer back online are minimal today > given we are largely talking about BGP propagation times, i.e.: likely > minutes. Ultimately, it's just those immediate upstream ISP's that need to > 'act' in order to propagate that route to the entire Internet. OTOH, in a > fully RPKI-enabled world, SP's the world over are performing origin > filtering using information from the RPKI at all of their customer and > peering interconnections ... this could make for some rather long > 'restoration' times so.. a few times now we've cycled around the time to get objects splayed out across the rpki/cache/router system. I think we agreed ~3months ago (?perhaps longer, someone can search the mail archive if interested) that timelines for publication -> all RP's have data was expected to be on the order of 10 minutes. I think danny handwaved that 5-10 minutes would be acceptable in his world. I also think that today (and for the next while) this timeline isn't important because folk mostly will be monitoring/marking and not dropping 'invalid' or 'unknown' routes. we could cycle around a few more times if it's of interest, but it seems to me... this is already solved, no? --e89a8f234659baabea04d96ba6c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Apr 2, 2013 at 10:25 PM, Shane Amante <shane@castlepoint.net> wrote:
=A0IOW, if (or, when) the matter is appropr= iately resolved, then (I suspect) the restoration times to get the customer= back online are minimal today given we are largely talking about BGP propa= gation times, i.e.: likely minutes. =A0Ultimately, it's just those imme= diate upstream ISP's that need to 'act' in order to propagate t= hat route to the entire Internet. =A0OTOH, in a fully RPKI-enabled world, S= P's the world over are performing origin filtering using information fr= om the RPKI at all of their customer and peering interconnections ... this = could make for some rather long 'restoration' times

so.. a few times now we= 9;ve cycled around the time to get objects splayed out across the rpki/cach= e/router system. I think we agreed ~3months ago (?perhaps longer, someone c= an search the mail archive if interested) that timelines for publication -&= gt; all RP's have data was expected to be on the order of 10 minutes. I= think danny handwaved that 5-10 minutes would be acceptable in his world.<= /div>

I also think that today (and for the next while) this timeline isn't i= mportant because folk mostly will be monitoring/marking and not dropping &#= 39;invalid' or 'unknown' routes. we could cycle around a few mo= re times if it's of interest, but it seems to me... this is already sol= ved, no?
--e89a8f234659baabea04d96ba6c8-- From kent@bbn.com Wed Apr 3 08:06:41 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A87421F8DDD for ; Wed, 3 Apr 2013 08:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp1xiPWbi3bo for ; Wed, 3 Apr 2013 08:06:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 87DFD21F8E34 for ; Wed, 3 Apr 2013 08:06:40 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51232) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UNPGl-0008pC-EF; Wed, 03 Apr 2013 11:06:35 -0400 Message-ID: <515C457B.1050502@bbn.com> Date: Wed, 03 Apr 2013 11:06:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Shane Amante References: <98cb8eeecc958523d8786b5503cc2d56@tcb.net> <5149C506.7080001@gmail.com> <5149D9A2.7030107@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E1D01BA@eusaamb109.ericsson.se> <514A098C.3040502@riw.us> <4B7D7C8E-273F-44DA-A705-0EB88E6459B4@istaff.org> <514A1336.4040202@riw.us> <3FB26F14-CF1B-4E5F-A8BA-416F32DB983E@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F66D0FE430@Hermes.columbia.ads.sparta.com> <51506B10.6050600@bbn.com> <9BAD9CCC-D6C7-467C-95CF-92BA47494E78@castlepoint.net> <515B1E87.7080605@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090905080701070306050901" Cc: sidr@ietf.org Subject: Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:06:41 -0000 This is a multi-part message in MIME format. --------------090905080701070306050901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Shane, > That is true. However, I feel the need to point a subtle, yet > important difference from today's environment. > > First, today, the ISP has direct knowledge prior to this 'event' > occurring and given the direct contractual relationship they have with > the customer the ISP would (IMO) be more likely to have a significant > business interest (i.e.: get paid) to ensure the order was valid, > applicable, etc. /before/ it was carried out. IOW, if the ISP is not > providing service to the customer, then the ISP may be unable to bill > for all or part of that service provided, (one, simple example: > usage-based billing). OTOH, if a third-party (RIR?) higher up the > allocation hierarchy were to "whack" a cert, thus making a cert for a > resource invalid can the same be said? Fair question. In the case of RIPE, where there was a LEO action that was somewhat analogous to ROA whacking, RIPE fought the action (in court). Only time will tell if other RIRs adopt a similar approach. > Second, consider the 'scope' of where such a change will be propagated > and a time-to-restore back to "normalcy" after the matter is > rectified. Today -- for better or worse -- it's the immediate > upstream ISP(s) of the targeted entity that, in your example, would be > curtailing the propagation of routes and/or forwarding to the > 'targeted entity' to/from the rest of the Internet. IOW, if (or, > when) the matter is appropriately resolved, then (I suspect) the > restoration times to get the customer back online are minimal today > given we are largely talking about BGP propagation times, i.e.: likely > minutes. Ultimately, it's just those immediate upstream ISP's that > need to 'act' in order to propagate that route to the entire Internet. I think that's a fair characterization of an example that I gave. > OTOH, in a fully RPKI-enabled world, SP's the world over are > performing origin filtering using information from the RPKI at all of > their customer and peering interconnections ... this could make for > some rather long 'restoration' times for the 'targeted entity' based > on several of the models I've seen tossed around in SIDR. And, the > longer the restoration times, again, the more noticeable the impact it > could have on the ISP's who provide service to/from the 'targeted > entity', (again: usage-based billing). When a targeted entity detects that it's ROA has been whacked, it can try to notify RPs (via out of band means). The easiest action for RPs to take if they choose to not act on the whacking is to retain the old data that they have cached. So, the time it would take to deal the whacking is determined by the time it takes to get the word out to RPs (after detection of the whacking. > Nonetheless, I will be interested to see if the paper you are writing > will include these types of detail. yes, it does. > >> if an RIR accidentally allocated the same prefix to two different >> entities, there would be a problem >> for one or both of them when they tried to advertise the >> twice-allocated space. > > While theoretically a possibility, I'd be curious to know if the above > is a common occurrence? If the RIR were concerned about this, one > quick way to ensure this did not happen would be for the RIR to > consult a "live" routing table to see if the space they are > (re-)allocating is already being announced somewhere. In fact, I'd be > surprised if they did not do this already. (Granted, this does not > prevent the same space from ever being twice allocated, because the > first allocation was sitting dormant/not-announced at that moment). I think this is a very, very unlikely failure case. I just mentioned it because others have cited this as a concern. Steve --------------090905080701070306050901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Shane,

That is true.  However, I feel the need to point a subtle, yet important difference from today's environment.

First, today, the ISP has direct knowledge prior to this 'event' occurring and given the direct contractual relationship they have with the customer the ISP would (IMO) be more likely to have a significant business interest (i.e.: get paid) to ensure the order was valid, applicable, etc. /before/ it was carried out.  IOW, if the ISP is not providing service to the customer, then the ISP may be unable to bill for all or part of that service provided, (one, simple example: usage-based billing).  OTOH, if a third-party (RIR?) higher up the allocation hierarchy were to "whack" a cert, thus making a cert for a resource invalid can the same be said?
Fair question. In the case of RIPE, where there was a LEO action that was somewhat analogous to ROA
whacking, RIPE fought the action (in court). Only time will tell if other RIRs adopt a similar approach.
Second, consider the 'scope' of where such a change will be propagated and a time-to-restore back to "normalcy" after the matter is rectified.  Today -- for better or worse -- it's the immediate upstream ISP(s) of the targeted entity that, in your example, would be curtailing the propagation of routes and/or forwarding to the 'targeted entity' to/from the rest of the Internet.  IOW, if (or, when) the matter is appropriately resolved, then (I suspect) the restoration times to get the customer back online are minimal today given we are largely talking about BGP propagation times, i.e.: likely minutes.  Ultimately, it's just those immediate upstream ISP's that need to 'act' in order to propagate that route to the entire Internet. 
I think that's a fair characterization of an example that I gave.
OTOH, in a fully RPKI-enabled world, SP's the world over are performing origin filtering using information from the RPKI at all of their customer and peering interconnections ... this could make for some rather long 'restoration' times for the 'targeted entity' based on several of the models I've seen tossed around in SIDR.  And, the longer the restoration times, again, the more noticeable the impact it could have on the ISP's who provide service to/from the 'targeted entity', (again: usage-based billing).
When a targeted entity detects that it's ROA has been whacked, it can try to notify RPs (via out of band means).
The easiest action for RPs to take if they choose to not act on the whacking is to retain the old data that
they have cached. So, the time it would take to deal the whacking is determined by the time it takes to
get the word out to RPs (after detection of the whacking.
Nonetheless, I will be interested to see if the paper you are writing will include these types of detail.
yes, it does.

if an RIR accidentally allocated the same prefix to two different entities, there would be a problem
for one or both of them when they tried to advertise the twice-allocated space.

While theoretically a possibility, I'd be curious to know if the above is a common occurrence?  If the RIR were concerned about this, one quick way to ensure this did not happen would be for the RIR to consult a "live" routing table to see if the space they are (re-)allocating is already being announced somewhere.  In fact, I'd be surprised if they did not do this already.  (Granted, this does not prevent the same space from ever being twice allocated, because the first allocation was sitting dormant/not-announced at that moment).
I think this is a very, very unlikely failure case. I just mentioned it because others have cited this as a
concern.

Steve
--------------090905080701070306050901-- From oleg@ripe.net Fri Apr 5 02:25:46 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C2821F970D for ; Fri, 5 Apr 2013 02:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eegcpK5nlBLb for ; Fri, 5 Apr 2013 02:25:46 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id D037121F9705 for ; Fri, 5 Apr 2013 02:25:45 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UO2tw-00087V-Uo; Fri, 05 Apr 2013 11:25:42 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest129.guestnet.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UO2nL-0003me-3R; Fri, 05 Apr 2013 11:18:51 +0200 Message-ID: <515E96FA.6020900@ripe.net> Date: Fri, 05 Apr 2013 11:18:50 +0200 From: Oleg Muravskiy Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17 MIME-Version: 1.0 To: Stephen Kent , sidr References: <51423B3E.6030804@bbn.com> <514725B4.6050707@gmail.com> <514ADC58.5080803@ripe.net> <514CFC5F.3090401@ripe.net> <515064E6.7030508@bbn.com> <515069D5.5040403@ripe.net> <51509B2E.2070108@bbn.com> <51518C9C.8040602@ripe.net> <5151B8CE.3000505@bbn.com> <5151C763.5060403@ripe.net> <5151CC02.20200@bbn.com> <5151D1F4.30307@ripe.net> <5151E481.8070409@bbn.com> In-Reply-To: <5151E481.8070409@bbn.com> Content-Type: multipart/alternative; boundary="------------000806010701050308080606" X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130405 clean X-RIPE-Spam-Level: ----- X-RIPE-Spam-Report: Spam Total Points: -5.3 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74b8c16941a173907a43b63722e93da06a Subject: Re: [sidr] comments on the repository analysis I-D X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 09:25:46 -0000 This is a multi-part message in MIME format. --------------000806010701050308080606 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Stephen Kent wrote: > Oleg, >> ... >> >> I'm not opposed to the 1AS = 1CA idea. It's just that in my mind RPKI associates with IP space holders, not AS operators, >> because this is how we do RPKI on RIR level. And on this level we already have more distinct IP space holders than the number of >> active AS. I don't know much about LIR to end user level, maybe the number of CAs there will be insignificant. > The RPKI is about who holds both sets of resources: addresses and AS#s. So, yes, as an RIR issuing certs > for address space, the focus is on address space holders. When we discuss using AS#'s to estimate the > number of CAs it is just because that seems like a reasonable estimator, not because it is the basis > for the management of address space. But RIRs will issue certificates to IP numbers holders, no matter how many AS# they have. This is a fact, not an estimator. And it already makes the number of CAs created by RIRs bigger than the number of ASes. So I do not see why you still insist that the total number of CAs is reasonably equal to the number of ASes. But the difference is not that big, so maybe we should mention in the requirements document all different estimations and stop this discussion. > I am curious, though. When RIPE acts as a CA on behalf of 1300+ entities with address space, have you > included the AS#s in the CA certs you issued, when the address space holders have AS#'s from RIPE? No, we do not include AS# in our certificates. -- Oleg Muravskiy RIPE NCC --------------000806010701050308080606 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Stephen Kent wrote:
Oleg,
...

I'm not opposed to the 1AS = 1CA idea. It's just that in my mind RPKI associates with IP space holders,  not AS operators, because this is how we do RPKI on RIR level. And on this level we already have more distinct IP space holders than the number of active AS. I don't know much about LIR to end user level, maybe the number of CAs there will be insignificant.
The RPKI is about who holds both sets of resources: addresses and AS#s. So, yes, as an RIR issuing certs
for address space, the focus is on address space holders. When we discuss using AS#'s to estimate the
number of CAs it is just because that seems like a reasonable estimator, not because it is the basis
for the management of address space.

But RIRs will issue certificates to IP numbers holders, no matter how many AS# they have. This is a fact, not an estimator.
And it already makes the number of CAs created by RIRs bigger than the number of ASes. So I do not see why you still insist that the total number of CAs is reasonably equal to the number of ASes.

But the difference is not that big, so maybe we should mention in the requirements document all different estimations and stop this discussion.

I am curious, though. When RIPE acts as a CA on behalf of 1300+ entities with address space, have you
included the AS#s in the CA certs you issued, when the address space holders have AS#'s from RIPE?

No, we do not include AS# in our certificates.

-- 
Oleg Muravskiy
RIPE NCC
--------------000806010701050308080606-- From tim@ripe.net Fri Apr 5 06:46:41 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340D621F97B3 for ; Fri, 5 Apr 2013 06:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy+2JW2c1rws for ; Fri, 5 Apr 2013 06:46:40 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 0F19621F97AE for ; Fri, 5 Apr 2013 06:46:39 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UO6yR-0007DY-Bp; Fri, 05 Apr 2013 15:46:38 +0200 Received: from cat.ripe.net ([193.0.1.249] helo=[IPv6:::1]) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1UO6yR-0004TW-6u; Fri, 05 Apr 2013 15:46:35 +0200 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=windows-1252 From: Tim Bruijnzeels In-Reply-To: Date: Fri, 5 Apr 2013 15:46:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51423B3E.6030804@bbn.com> <514725B4.6050707@gmail.com> <514ADC58.5080803@ripe.net> <514CFC5F.3090401@ripe.net> <515064E6.7030508@bbn.com> <51517215.9010602@ripe.net> <5151C843.2040803@ripe.net> <8DA1853CE466B041B104C1CAEE00B3748FA49A81@CHAXCH01.corp.arin.net> <5152F74B.9020800@ripe.net> <5152F8F9.6040505@lacnic.net> <51531E52.4070303@lacnic.net> <515321BB.2070601@lacnic.net> To: Randy Bush X-Mailer: Apple Mail (2.1503) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130405 clean X-RIPE-Spam-Level: ----- X-RIPE-Spam-Report: Spam Total Points: -5.3 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719ca141b9e57fefac67321a27d9cbd40f6 Cc: sidr@ietf.org Subject: Re: [sidr] comments on the repository analysis I-D X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 13:46:41 -0000 On 27 Mar, 2013, at 6:24 PM, Randy Bush wrote: >> Yes, I assume >> http://tools.ietf.org/agenda/86/slides/slides-86-sidr-1.pdf slide 3. >> Which I think is a good estimate. >=20 > actually, i think the number of pub points will be closer to the = number > of entries in the rir's datamesses, as they will be issuing the certs > based on their data messes. Indeed. I disagree that the number of AS#s is a good estimator for the number of = publication points. As OIeg, and others, also mentioned the RIRs issue certificates based on = the resources they know are held by organisations. Resources can be any = combination of 0 or more AS#, 0 or more IPv4 prefixes and 0 or more IPv6 = prefixes. So the number of distinct resource holders that the RIRs see = is the estimator that is suitable here. There is a group of = organisations that hold IP prefixes, but do not run their own AS. This = group is missing from the slide. Oleg made this estimate based on current stats: > =46rom the RIR stats files that RIRs publish daily we could get the = numbers of distinct resource holders. They are: >=20 > AFRINIC 1310 > APNIC 7957 > ARIN 35380 > LACNIC 4278 >=20 > For the RIPE NCC you could not get this data from stats files, and the = exact number is difficult to get because of our model of = provider-independent end users. But in our registry I could count that = it is at least 28912. > That brings the total to 77837. After comments by Randy and John Curran it seems that the number for = ARIN obtained here is too high. John suggested 50%. So then the total = number would be roughly 60000. (no not trying to be more exact than the = error term here, it's the ball park that matters) So that's roughly 60k certificates that are going to published and, = associated, 60k mfts + 60k crls. Note, this is the boilerplate RPKI, just the 'publication points' and = the objects necessary to support that. The, more useful, content is a different story. I was looking for = ballpark total numbers for ghostbusters, roas and router certs, but I = don't believe that the number of publication points (~certified = organisations) is the most important variable in each case. See below. =3D ghostbusters Okay, in this case I actually do believe that it will correlate most = strongly with the number of publication points.. It seems a reasonable = estimate be that each publication point will publish one record for all = their resources. But, there is room for error here.. maybe some = organisations will publish many records for specific resources they = have. Others may just have one with everything. Yet others may publish = none=85 My current best guess is 1 per publication point, on average. So roughly = 60k in total. I am more than happy to change this number in the model with a better = estimate. Another approach could be to look at the current RIR databases and model = this after the number of equivalent contacts found there now. =3D roas I am not convinced by the 1 ROA per AS. Aggregating all possible routes = for an AS on a single ROA is not feasible. As mentioned above it's the = prefix holders that make these ROAs. They may, or may not be holder of = the AS. In practice there is a sizeable group of organisation who do not = run their own AS. In our document we figured that looking at the number of announcements = in the current routing table, and the maximum aggregation factor of = prefixes per ROA that we see today gives a reasonable estimate for the = amount of ROAs needed to make all intended announcements appear valid. = But the aggregation factor is quite fuzzy.. in particular it's difficult = to deal with max length this way... I just thought of another much simpler approach that seems better to = me... Based on the RIPE NCC router collector dumps: http://www.ris.ripe.net/dumps/ And validation we do on the current RIR datasets. We see: =3D 479608 total announcements =3D 10692 valid announcements =3D 1197 ROA objects So, average number of routes made valid by a ROA: 10692 / 1197 =3D> 8.9 = something. So to get the number of ROAs needed to make all 479k announcements = valid: 497608 / 8.9 =3D> 53693 =3D router certificates We explicitly mention this in our document: > All in all it is not entirely clear to the authors how many certified = keys may be, but on list numbers as high as 2,000,000 have been = mentioned. Router certificates are used by ASes. So the model proposed by Stephen = en Sririam seems reasonable to me: # non-stub ASes * avg certs per non-stub AS + # stub ASes * avg certs = per stub AS. Or with values: 36,120 non-stub AS * 10 + 6,880 stub AS * 2 =3D 374960. Open to suggestions.. Tim -- Back from long holidays..= From internet-drafts@ietf.org Fri Apr 5 15:18:10 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8604E21F98FE; Fri, 5 Apr 2013 15:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDzc3VKl+9Pd; Fri, 5 Apr 2013 15:18:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2DC21F9906; Fri, 5 Apr 2013 15:18:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130405221809.6404.3428.idtracker@ietfa.amsl.com> Date: Fri, 05 Apr 2013 15:18:09 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ltamgmt-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:18:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Local Trust Anchor Management for the Resource Public Ke= y Infrastructure Author(s) : Mark C. Reynolds Stephen Kent Matthew Lepinski Filename : draft-ietf-sidr-ltamgmt-08.txt Pages : 28 Date : 2013-04-05 Abstract: This document describes a facility to enable a relying party (RP) to manage trust anchors (TAs) in the context of the Resource Public Key Infrastructure (RPKI). It is common in RP software (not just in the RPKI) to allow an RP to import TA material in the form of self-signed certificates. However, this approach to incorporating TAs is potentially dangerous. (These self-signed certificates rarely incorporate any extensions that impose constraints on the scope of the imported public keys, and the RP is not able to impose such constraints.) The facility described in this document allows an RP to impose constraints on such TAs. Because this mechanism is designed to operate in the RPKI context, the most important constraints are the Internet Number Resources (INRs) expressed via RFC 3779 extensions. These extentions bind address spaces and/or autonomous system (AS) numbers to entities. The primary motivation for the facility described in this document is to enable an RP to ensure that INR information that it has acquired via some trusted channel is not overridden by the information acquired from the RPKI repository system or by the putative TAs that the RP imports. Specifically, the mechanism allows an RP to specify a set of overriding bindings between public key identifiers and INR data. These bindings take precedence over any conflicting bindings acquired by the putative TAs and the certificates downloaded from the RPKI repository system. This mechanism is designed for local use by an R= P, but any entity that is accorded administrative control over a set of RPs may use this mechanism to convey its view of the RPKI to RPs within its jurisdiction. The means by which this latter use case is effected is outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-ltamgmt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-ltamgmt-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-ltamgmt-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From oliver.borchert@nist.gov Mon Apr 8 13:28:10 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA9621F913E for ; Mon, 8 Apr 2013 13:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApqEQWybdmzv for ; Mon, 8 Apr 2013 13:28:09 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 5489521F8D8F for ; Mon, 8 Apr 2013 13:28:09 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 8 Apr 2013 16:27:31 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 8 Apr 2013 16:28:07 -0400 From: "Borchert, Oliver" To: "sidr wg list (sidr@ietf.org)" Date: Mon, 8 Apr 2013 16:28:06 -0400 Thread-Topic: Announcing BGP-SRx 0.3.0 service release Thread-Index: Ac40l5KKfgkyTo67TLe8z/pI0ymNVQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930BFE5168BAMBCLUSTERxcha_" MIME-Version: 1.0 Subject: [sidr] Announcing BGP-SRx 0.3.0 service release X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 20:28:10 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930BFE5168BAMBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" This is to announce the BGP Secure Router Extension (BGP-SRx) Version 0.3 Prototype Implementation. This release includes extensive performance and robustness improvements, multi router support, re-design/re-write of the Quagga integration, and many bug fixes. BGP-SRx is an open source reference implementation and research platform for investigating emerging BGP security extensions and supporting protocols. The BGP-SRx suite consists of three parts: (1) SRx Server, (2) SRx API, and (3) Quagga-SRx (which integrates the SRx API into the Quagga router). The focus is on origin validation, although it is designed to be extended to path validation. Stub functionality for path validation is included in this version. Additionally, this release contains an SRx client/server test harnesses and a simple RPKI validation cache simulator (VCS). The VCS allows to manually feed ROA information into BGP-SRx server using the RPKI to Router protocol (rfc6810) as well as WireShark modules for debugging. For more information on BGP-SRx, and to download the prototype and tools, see: http://www-x.antd.nist.gov/bgpsrx/ Comments and feedback about BGP-SRx are welcome. See the project page for details. Thanks, Oliver Borchert ------------------------------------------------------------- Oliver Borchert, Computer Scientist National Institute of Standards and Technology (Phone) 301.975.4856 , (Fax) 301.975.6238 --_000_D7A0423E5E193F40BE6E94126930C4930BFE5168BAMBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJh Z3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCglt YXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0K CW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxMDUwNjg1MjE3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMjEzNDc5OTQ4IDE4NzQxMTI0NDIgNjc2OTg3MTMgNjc2OTg3MTUg Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiJcKCUxXCkiOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDouNzVpbjsNCgl0ZXh0LWluZGVudDotLjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNs YXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2snPlRoaXMgaXMgdG8gYW5u b3VuY2UgdGhlIEJHUCBTZWN1cmUgUm91dGVyIEV4dGVuc2lvbiAoQkdQLVNSeCkgVmVyc2lvbiAw LjMgUHJvdG90eXBlIEltcGxlbWVudGF0aW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOmJsYWNrJz5UaGlzIHJlbGVhc2UgaW5jbHVkZXMgZXh0ZW5zaXZlIHBlcmZv cm1hbmNlIGFuZCByb2J1c3RuZXNzIGltcHJvdmVtZW50cywgPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjpibGFjayc+bXVsdGkgcm91dGVyIHN1cHBvcnQsIHJlLWRlc2ln bi9yZS13cml0ZSBvZiB0aGUgUXVhZ2dhIGludGVncmF0aW9uLCA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrJz5hbmQgbWFueSBidWcgZml4ZXMuIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox My41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2snPkJHUC1TUnggaXMgYW4gb3BlbiBz b3VyY2UgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uIGFuZCByZXNlYXJjaCBwbGF0Zm9ybSA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrJz5mb3IgaW52ZXN0aWdh dGluZyBlbWVyZ2luZyBCR1Agc2VjdXJpdHkgZXh0ZW5zaW9ucyBhbmQgc3VwcG9ydGluZyBwcm90 b2NvbHMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2snPlRo ZSBCR1AtU1J4IHN1aXRlIGNvbnNpc3RzIG9mIHRocmVlIHBhcnRzOiA8YnI+KDEpIFNSeCBTZXJ2 ZXIsICgyKSBTUnggQVBJLCBhbmQgKDMpIFF1YWdnYS1TUnggKHdoaWNoIGludGVncmF0ZXMgdGhl IFNSeCBBUEkgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayc+ aW50byB0aGUgUXVhZ2dhIHJvdXRlcikuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6YmxhY2snPlRoZSBmb2N1cyBpcyBvbiBvcmlnaW4gdmFsaWRhdGlvbiwgYWx0aG91 Z2ggaXQgaXMgZGVzaWduZWQgdG8gYmUgZXh0ZW5kZWQgdG8gPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjpibGFjayc+cGF0aCB2YWxpZGF0aW9uLiBTdHViIGZ1bmN0aW9u YWxpdHkgZm9yIHBhdGggdmFsaWRhdGlvbiBpcyBpbmNsdWRlZCBpbiB0aGlzPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayc+dmVyc2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrJz5BZGRpdGlvbmFsbHksIHRoaXMgcmVsZWFz ZSBjb250YWlucyBhbiBTUnggY2xpZW50L3NlcnZlciB0ZXN0IGhhcm5lc3NlcyBhbmQgYTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2snPnNpbXBsZSBSUEtJIHZh bGlkYXRpb24gY2FjaGUgc2ltdWxhdG9yIChWQ1MpLiBUaGUgVkNTIGFsbG93cyB0byBtYW51YWxs eSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrJz5mZWVkIFJP QSBpbmZvcm1hdGlvbiBpbnRvIEJHUC1TUnggc2VydmVyIHVzaW5nIHRoZSBSUEtJIHRvIFJvdXRl ciBwcm90b2NvbCAocmZjNjgxMCkgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjpibGFjayc+YXMgd2VsbCBhcyBXaXJlU2hhcmsgbW9kdWxlcyBmb3IgZGVidWdnaW5nLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2snPkZvciBtb3JlIGluZm9y bWF0aW9uIG9uIEJHUC1TUngsIGFuZCB0byBkb3dubG9hZCB0aGUgcHJvdG90eXBlIGFuZCB0b29s cywgc2VlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2snPjxh IGhyZWY9Imh0dHA6Ly93d3cteC5hbnRkLm5pc3QuZ292L2JncHNyeC8iPmh0dHA6Ly93d3cteC5h bnRkLm5pc3QuZ292L2JncHNyeC88L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjpibGFjayc+Q29tbWVudHMgYW5kIGZlZWRiYWNrIGFib3V0IEJHUC1TUnggYXJlIHdlbGNv bWUuIFNlZSB0aGUgcHJvamVjdCBwYWdlIGZvciBkZXRhaWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6YmxhY2snPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrJz5PbGl2ZXIgQm9yY2hlcnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+T2xpdmVyIEJvcmNoZXJ0LCBDb21wdXRlciBTY2llbnRpc3Q8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+TmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5v bG9neTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4oUGhvbmUpIDMwMS45NzUuNDg1 NiAsIChGYXgpIDMwMS45NzUuNjIzODxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_D7A0423E5E193F40BE6E94126930C4930BFE5168BAMBCLUSTERxcha_-- From randy@psg.com Mon Apr 8 17:57:37 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8C021F8E6E for ; Mon, 8 Apr 2013 17:57:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwzJcdRZuVwb for ; Mon, 8 Apr 2013 17:57:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2A821F8E63 for ; Mon, 8 Apr 2013 17:57:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UPMsS-0002Ae-Iu for sidr@ietf.org; Tue, 09 Apr 2013 00:57:36 +0000 Date: Tue, 09 Apr 2013 09:57:53 +0900 Message-ID: From: Randy Bush To: sidr wg list References: <20130409005340.26017.92925.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] draft-ymbk-rpki-rtr-keys-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 00:57:37 -0000 chairs, could you please turn the crank to move this through wg adoption? thanks fwiw, i doubt it will move through to wglc/rfc, but rather a 6810bis may be the better path. randy From: internet-drafts@ietf.org To: randy@psg.com Cc: keyupate@cisco.com, turners@ieca.com Subject: New Version Notification for draft-ymbk-rpki-rtr-keys-01.txt Message-ID: <20130409005340.26017.92925.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 17:53:40 -0700 A new version of I-D, draft-ymbk-rpki-rtr-keys-01.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Filename: draft-ymbk-rpki-rtr-keys Revision: 01 Title: Router Key PDU for RPKI-Router Protocol Creation date: 2013-04-09 Group: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-ymbk-rpki-rtr-ke= ys-01.txt Status: http://datatracker.ietf.org/doc/draft-ymbk-rpki-rtr-keys Htmlized: http://tools.ietf.org/html/draft-ymbk-rpki-rtr-keys-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ymbk-rpki-rtr-key= s-01 Abstract: The RPKI/Router Protocol v0 is specified to carry the PDUs necessary for RPKI-based Origin Validation. For BGPsec Path Validation, the routers also need data extracted from BGPsec Router Certificates. This document adds a PDU to the RPKI/Router Protocol to carry those data. The IETF Secretariat From internet-drafts@ietf.org Wed Apr 10 08:58:17 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A16B21F98BC; Wed, 10 Apr 2013 08:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.329 X-Spam-Level: X-Spam-Status: No, score=-102.329 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiwQZo+GOsID; Wed, 10 Apr 2013 08:58:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF08F21F9728; Wed, 10 Apr 2013 08:58:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130410155814.9130.14908.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2013 08:58:14 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-grandparenting-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 15:58:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Responsible Grandparenting in the RPKI Author(s) : Randy Bush Filename : draft-ietf-sidr-rpki-grandparenting-01.txt Pages : 4 Date : 2013-04-10 Abstract: There are circumstances in RPKI operation where a resource holder's parent may not be able to, or may not choose to, facilitate full and proper registration of the holder's data. As in real life, the holder may form a relationship with their grandparent who is willing to aid the grandchild. This document describes simple procedures for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-grandparenting There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-grandparenting-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpki-grandparenting-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dmandelb@bbn.com Wed Apr 10 10:39:43 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8DE21F8F56 for ; Wed, 10 Apr 2013 10:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3I8azmBTlbh for ; Wed, 10 Apr 2013 10:39:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id DCD6F21F8F53 for ; Wed, 10 Apr 2013 10:39:42 -0700 (PDT) Received: from smp.bbn.com ([192.1.122.26]:45516) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UPyzj-0006OC-U6; Wed, 10 Apr 2013 13:39:39 -0400 Received: from dhcp89-089-068.bbn.com ([128.89.89.68]:59725) by smp.bbn.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1UPyzj-000OMz-QF; Wed, 10 Apr 2013 13:39:39 -0400 Message-ID: <1365615580.2642.80.camel@titan> From: David Mandelberg To: rpstir-announce@bbn.com Date: Wed, 10 Apr 2013 13:39:40 -0400 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Authenticated-User: dmandelb Cc: rpki@rpki.net, sidr@ietf.org Subject: [sidr] rpstir-0.7 released X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 17:39:43 -0000 Hi all, We just released version 0.7 of our relying party software, rpstir. This version is primarily a bugfix release with fixes for bugs we found at the relying party testing session at IETF 86. Download: https://sourceforge.net/projects/rpstir/ Contact: rpstir-support@bbn.com From wwwrun@rfc-editor.org Wed Apr 10 16:37:48 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD5021F8CDE; Wed, 10 Apr 2013 16:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5rxLZFEgIbh; Wed, 10 Apr 2013 16:37:48 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 36F9521F8CD2; Wed, 10 Apr 2013 16:37:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F12AFB1E00A; Wed, 10 Apr 2013 16:37:10 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130410233710.F12AFB1E00A@rfc-editor.org> Date: Wed, 10 Apr 2013 16:37:10 -0700 (PDT) Cc: sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] BCP 182, RFC 6916 on Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 23:37:48 -0000 A new Request for Comments is now available in online RFC libraries. BCP 182 RFC 6916 Title: Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) Author: R. Gagliano, S. Kent, S. Turner Status: Best Current Practice Stream: IETF Date: April 2013 Mailbox: rogaglia@cisco.com, kent@bbn.com, turners@ieca.com Pages: 20 Characters: 48395 See Also: BCP0182 I-D Tag: draft-ietf-sidr-algorithm-agility-12.txt URL: http://www.rfc-editor.org/rfc/rfc6916.txt This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From internet-drafts@ietf.org Fri Apr 12 04:13:34 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B7C21F8A68; Fri, 12 Apr 2013 04:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.302 X-Spam-Level: X-Spam-Status: No, score=-102.302 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-dEZc6AUuxP; Fri, 12 Apr 2013 04:13:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB6321F8A08; Fri, 12 Apr 2013 04:13:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130412111333.2956.38698.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2013 04:13:33 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:13:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Security Requirements for BGP Path Validation Author(s) : Steven M. Bellovin Randy Bush David Ward Filename : draft-ietf-sidr-bgpsec-reqs-07.txt Pages : 9 Date : 2013-04-12 Abstract: This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-reqs-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Sandra.Murphy@sparta.com Sat Apr 13 04:16:11 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A20921F8960 for ; Sat, 13 Apr 2013 04:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.593 X-Spam-Level: X-Spam-Status: No, score=-101.593 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkrxcNyiuZeO for ; Sat, 13 Apr 2013 04:16:10 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id B446C21F890D for ; Sat, 13 Apr 2013 04:16:08 -0700 (PDT) Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r3DBG8tA011396 for ; Sat, 13 Apr 2013 06:16:08 -0500 Received: from Hermes.columbia.ads.sparta.com ([10.62.56.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r3DBG2sW024991 for ; Sat, 13 Apr 2013 06:16:08 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%18]) with mapi id 14.02.0247.003; Sat, 13 Apr 2013 07:15:58 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: minutes were posted Thread-Index: Ac44N8uMSrxuznMtRwietUb+1ZtbAw== Date: Sat, 13 Apr 2013 11:15:57 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F66EDF962E@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] minutes were posted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 11:16:11 -0000 The draft minutes were posted yesterday. You can find them at http://www.i= etf.org/proceedings/86/minutes/minutes-86-sidr.=0A= =0A= Many thanks to our minutes takers, Jeff and Sriram, who had to keep up with= some very energetic discussions during the meeting! It is very much appre= ciated.=0A= =0A= Please do review the minutes. Send any corrections or additions to the lis= t. Any changes must be made before 1 May 2013, when the proceedings will b= e declared final.=0A= =0A= --Sandy, speaking as wg co-chair= From eosterweil@verisign.com Mon Apr 15 12:15:59 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A74E21F9452 for ; Mon, 15 Apr 2013 12:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70Vlu60qZ+3v for ; Mon, 15 Apr 2013 12:15:58 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5B20B21F942C for ; Mon, 15 Apr 2013 12:15:58 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKUWxR7Sj1UmfQwccO6DBiKlPl4VfIut0J@postini.com; Mon, 15 Apr 2013 12:15:58 PDT Received: from DUL1WNSMTP01.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r3FJFsjo022622 for ; Mon, 15 Apr 2013 15:15:56 -0400 Received: from dul1osterwe-m2.vcorp.ad.vrsn.com ([10.88.29.76]) by DUL1WNSMTP01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(7.5.7601.17514); Mon, 15 Apr 2013 15:15:54 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Osterweil, Eric" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F66EDF962E@Hermes.columbia.ads.sparta.com> Date: Mon, 15 Apr 2013 15:15:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <404B6C36-2A6B-446E-A1F3-9DC3505B1AB1@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F66EDF962E@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1499) X-OriginalArrivalTime: 15 Apr 2013 19:15:54.0206 (UTC) FILETIME=[A675FFE0:01CE3A0D] Cc: "sidr@ietf.org" Subject: Re: [sidr] minutes were posted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:15:59 -0000 Correction (clever spelling of name) + additional response (required for = context of later minutes): --------- Eric Osterwilde: These numbers look close to independently = arrived numbers. SK: They came from you. --- should be ---- Eric Osterweil: These numbers look close to independently = arrived numbers. SK: They came from you. EO: No they didn't, as evidenced by the lack of citation and = small (but measurable) differences in the numbers --------- Eric On Apr 13, 2013, at 7:15 AM, "Murphy, Sandra" = wrote: > The draft minutes were posted yesterday. You can find them at = http://www.ietf.org/proceedings/86/minutes/minutes-86-sidr. >=20 > Many thanks to our minutes takers, Jeff and Sriram, who had to keep up = with some very energetic discussions during the meeting! It is very = much appreciated. >=20 > Please do review the minutes. Send any corrections or additions to = the list. Any changes must be made before 1 May 2013, when the = proceedings will be declared final. >=20 > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > =93This message (including any attachments) is intended only for the = use of the individual or entity to which it is addressed, and may = contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be = constituted as attorney work product. If you are not the intended = recipient, you are hereby notified that any use, dissemination, = distribution, or copying of this communication is strictly prohibited. = If you have received this message in error, notify sender immediately = and delete this message immediately.=94 From internet-drafts@ietf.org Mon Apr 15 14:34:55 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AD721F9408; Mon, 15 Apr 2013 14:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.329 X-Spam-Level: X-Spam-Status: No, score=-102.329 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oz6LRmPIhhI; Mon, 15 Apr 2013 14:34:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC5421F9409; Mon, 15 Apr 2013 14:34:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130415213454.11713.86219.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2013 14:34:54 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-rollover-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 21:34:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : BGPSEC router key rollover as an alternative to beaconing Author(s) : Roque Gagliano Keyur Patel Brian Weis Filename : draft-ietf-sidr-bgpsec-rollover-02.txt Pages : 9 Date : 2013-04-15 Abstract: BGPSEC will need to address the impact from regular and emergency rollover processes for the BGPSEC End-Entity (EE) certificates that will be performed by Certificate Authorities (CAs) participating at the Resource Public Key Infrastructure (RPKI). This document provides general recommendations for that process and specifies how this process is used to control BGPSEC's window of exposure to replay attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rollover There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-rollover-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From baerm@mikesoffice.com Tue Apr 16 16:19:33 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E31221F9757 for ; Tue, 16 Apr 2013 16:19:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+vVr66O3UjE for ; Tue, 16 Apr 2013 16:19:32 -0700 (PDT) Received: from mail.mikesoffice.com (v6.mikesoffice.com [IPv6:2001:470:1f05:274::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD7A21F9777 for ; Tue, 16 Apr 2013 16:19:32 -0700 (PDT) Received: from localhost (unknown [173.239.75.179]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 1FDD49DB7B; Tue, 16 Apr 2013 16:19:30 -0700 (PDT) From: Michael Baer To: sidr@ietf.org X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: [sidr] Announce a BGPSEC implementation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 23:19:33 -0000 Hi all, We've been working on BGPSEC implementation based on the BIRD software package. It's currently in an alpha state but supports most of the BGPSEC protocol (no confederation or algorithm rollover). If anyone would like to play with it, I would appreciate any feedback. Below is a link to README and patch against v1.3.9 of BIRD. http://bgpsec.tislabs.com/ Thanks, -Mike -- Michael Baer PARSONS baerm@tislabs.com From internet-drafts@ietf.org Wed Apr 17 18:31:28 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3BA21F88E3; Wed, 17 Apr 2013 18:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfOngs0hUqUY; Wed, 17 Apr 2013 18:31:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D4F21F88B9; Wed, 17 Apr 2013 18:31:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130418013127.28598.42851.idtracker@ietfa.amsl.com> Date: Wed, 17 Apr 2013 18:31:27 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 01:31:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : A Profile for BGPSEC Router Certificates, Certificate Re= vocation Lists, and Certification Requests Author(s) : Mark Reynolds Sean Turner Steve Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-05.txt Pages : 11 Date : 2013-04-17 Abstract: This document defines a standard profile for X.509 certificates for the purposes of supporting validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPSEC. BGP is a critical component for the proper operation of the Internet as a whole. The BGPSEC protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPSEC is to design a protocol for full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued under Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificates, containing the AS Identifier Delegation extension, to routers within the Autonomous System (AS). The certificate asserts that the router(s) holding the private key are authorized to send out secure route advertisements on behalf of the specified AS. This document also profiles the Certificate Revocation List (CRL), profiles the format of certification requests, and specifies Relying Party certificate path validation procedures. The document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From turners@ieca.com Thu Apr 18 05:32:35 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21F321F8E79 for ; Thu, 18 Apr 2013 05:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL8dbLMid7Q2 for ; Thu, 18 Apr 2013 05:32:35 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [64.5.38.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFC521F8E46 for ; Thu, 18 Apr 2013 05:32:35 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id EBDA0E9875F30; Thu, 18 Apr 2013 07:32:08 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway09.websitewelcome.com (Postfix) with ESMTP id DD813E9875F09 for ; Thu, 18 Apr 2013 07:32:08 -0500 (CDT) Received: from [108.18.174.101] (port=60543 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1USo0w-0005lQ-JE for sidr@ietf.org; Thu, 18 Apr 2013 07:32:34 -0500 Message-ID: <516FE7E1.3070001@ieca.com> Date: Thu, 18 Apr 2013 08:32:33 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: sidr@ietf.org References: <20130418013127.28598.42851.idtracker@ietfa.amsl.com> In-Reply-To: <20130418013127.28598.42851.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.101]:60543 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 12:32:35 -0000 This is just a keep alive version. Date changes only. spt On 4/17/13 9:31 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests > Author(s) : Mark Reynolds > Sean Turner > Steve Kent > Filename : draft-ietf-sidr-bgpsec-pki-profiles-05.txt > Pages : 11 > Date : 2013-04-17 > > Abstract: > This document defines a standard profile for X.509 certificates for > the purposes of supporting validation of Autonomous System (AS) paths > in the Border Gateway Protocol (BGP), as part of an extension to that > protocol known as BGPSEC. BGP is a critical component for the proper > operation of the Internet as a whole. The BGPSEC protocol is under > development as a component to address the requirement to provide > security for the BGP protocol. The goal of BGPSEC is to design a > protocol for full AS path validation based on the use of strong > cryptographic primitives. The end-entity (EE) certificates specified > by this profile are issued under Resource Public Key Infrastructure > (RPKI) Certification Authority (CA) certificates, containing the AS > Identifier Delegation extension, to routers within the Autonomous > System (AS). The certificate asserts that the router(s) holding the > private key are authorized to send out secure route advertisements on > behalf of the specified AS. This document also profiles the > Certificate Revocation List (CRL), profiles the format of > certification requests, and specifies Relying Party certificate path > validation procedures. The document extends the RPKI; therefore, > this documents updates the RPKI Resource Certificates Profile (RFC > 6487). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From alexey.melnikov@isode.com Tue Apr 23 08:00:31 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E3921F969C for ; Tue, 23 Apr 2013 08:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.746 X-Spam-Level: X-Spam-Status: No, score=-100.746 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5H1zT18CLBy9 for ; Tue, 23 Apr 2013 08:00:31 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD8C21F968B for ; Tue, 23 Apr 2013 08:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1366729230; d=isode.com; s=selector; i=@isode.com; bh=q5jqB9oBiqy9ejpC0/fuEpGzKDtQnehB3IdF8F3ATFw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=XWIyeh7pMS0IkF2TcAd4+3pPoIadYKKe1hBApnJfOGLiXhvDMuEEEuyGLBsP0XYxl4W+91 LTgIJ4SXufZxF2y9uxYx3PSKECHb7P9epFShf95L9eN0yRnCRbSEqEV2FAc4zJHYxsGdQd t6C/P8MI7KjwLzdxUlJ4Vo6rchhGsdc=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 23 Apr 2013 16:00:29 +0100 Message-ID: <5176A20D.9050607@isode.com> Date: Tue, 23 Apr 2013 16:00:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: sidr wg MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Results of the acceptance call for draft-newton-sidr-policy-qualifiers-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 15:00:32 -0000 Multiple people voiced their support for adopting the document, a couple of people provided specific comments. Nobody voiced their opposition to adopting the document. WG participants have spoken, so the document is now adopted by the WG. Best Regards, Alexey, as a co-chair. From hammondjohnson@hushmail.com Sat Apr 27 15:49:55 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5097F21F98F7 for ; Sat, 27 Apr 2013 15:49: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCdFo-qlb7ok for ; Sat, 27 Apr 2013 15:49:55 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id E9A4A21F99D2 for ; Sat, 27 Apr 2013 15:49:53 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id C690A30545 for ; Sat, 27 Apr 2013 18:01:12 +0000 (UTC) X-hush-relay-time: 220 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 18:01:12 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 89A20E6736; Sat, 27 Apr 2013 18:01:12 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 14:01:12 -0400 To: sidr@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427180112.89A20E6736@smtp.hushmail.com> Subject: [sidr] Biggest Fake Conference in Computer Science X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 22:49:55 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.