[sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

Interesting presentation here: http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf "The RPKI (Resource Public Key Infrastructure) is a new infrastructure to secure Internet routing It’s been in deployment since ~2011 But, it also creates new risks (misconfigurations and takedowns) that

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Mar 20, 2013, at 6:50 AM, Danny McPherson wrote: > Interesting presentation here: > > http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf > > "The RPKI (Resource Public Key Infrastructure) is a new infrastructure to > secure Internet routing > It’s been in deployment since ~2011 But, i

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

And THE organization can also take down bgp-peers, shutdown interfaces, etc. At the end, it is its space, they can revoke certs. Cheers, as On 3/20/13 9:50 AM, Danny McPherson wrote: > > Interesting presentation here: > > http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pd

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

> Danny - Is there really a "tight coupling" if providers are > following the recommend BGP origin validation best practices? I said BGPSEC... -danny ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Mar 20, 2013, at 7:21 AM, Danny McPherson wrote: >> Danny - Is there really a "tight coupling" if providers are >> following the recommend BGP origin validation best practices? > > I said BGPSEC... Got it - the presentation suggests that RPKI poses risks to network reachability due to att

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

I agree with John's observations. We need to stop making the statement "no roa == no route", because it's simply not true. So far in my reading of the full paper, many of the 'vulnerabilities' they mention (quotes intended, I'm not sure the word is properly applied given the context) appear to (

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

Danny, Thanks for the link. I read the doc. I do not believe the work has been peer-reviewed and I detected a couple of bizarre statements (such as deleting an object = revocation or the idea of "overwriting" a ROA to replace an existing one). What I believe it adds to our work are a number of

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

Hey Danny, I read the paper. Maybe it's that I'm missing the voice-over for the slides, but I don't really see anything new here. Every new security mechanism creates a new DOS possibility. If you screw up your HTTPS cert or your CA revokes it, your website goes down. This happens because only

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On 2013-03-20 09:00, Roque Gagliano (rogaglia) wrote: I do not believe the work has been peer-reviewed and I detected a couple of bizarre statements (such as deleting an object = revocation or the idea of "overwriting" a ROA to replace an existing one). Much of the work presented here is not "

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On 2013-03-20 09:15, Richard Barnes wrote: One other thing to note is that manipulation is indistinguishable from legitimate revocation, at a technical level.  So the only solution here is at the human layer, for RPKI relying party software to have operator overrides.  Randy stated this better

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

> I agree with John's observations. We need to stop making the statement > "no roa == no route", because it's simply not true. There's something I probably don't understand here... 1. SIDR's ROA/RPKI infrastructure is designed to provide security for route origination. 2. Security for route ori

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

inline. On Mar 20, 2013, at 4:21 PM, Danny McPherson wrote: > On 2013-03-20 09:00, Roque Gagliano (rogaglia) wrote: > >> I do not believe the work has been peer-reviewed and I detected a >> couple of bizarre statements (such as deleting an object = revocation >> or the idea of "overwriting" a R

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On , Russ White <> wrote: >> I agree with John's observations. We need to stop making the >> statement "no roa == no route", because it's simply not true. > > There's something I probably don't understand here... > > 1. SIDR's ROA/RPKI infrastructure is designed to provide security for > route o

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

> There is a difference. > Invalid: someone is certified to own it and someone ELSE is originating. > Unknown: No one is certified owner. Yes, I know that --but when someone says this: > I agree with John's observations. We need to stop making the > statement "no roa == no route", because it's s

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Mar 20, 2013, at 1:10 PM, Russ White wrote: > In response to a paper that says removing ROAs is a form of DoS, or that > there are potential problems in the space of the relationship between > the registry and the address owner, then we've moved from "unknown," to > "contested." The response g

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

> Loss of a ROA (e.g. due to an attack on the RPKI system) does not > cause a _reachability event_ if folks are using best practices for > route precedence; that's what was implied in the paper and is wrong. > Successful attacks against the RPKI system do have an impact, but it > is simply th

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

Speaking as a regular ol' member >It seems, to me, that if the RPKI can't be used to actually validate who >owns what route with certainty, we're going to a lot of trouble for >nothing... Or maybe folks are trying to have their cake and eat it to. >"We'll provide solid security which you can ignor

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Mar 20, 2013, at 1:51 PM, Russ White wrote: > How often do you think an attacker would bother with taking out a ROA > without taking out the route as well? Invert the question... Of the thousands of entities that could today inject (hostile) routes and do a hijack today, how many of them wil

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

>> It seems, to me, that if the RPKI can't be used to actually validate who >> owns what route with certainty, we're going to a lot of trouble for >> nothing... Or maybe folks are trying to have their cake and eat it to. >> "We'll provide solid security which you can ignore if you like, no >> prob

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

>> 1. Removing the ROAs is a problem in terms of increased risk, which is a >> problem which needs to be addressed. > > I never argued with addressing the risks that might be posed; I was pointing > out that the risk does not equate (on its own) with a reachability event, as > alluded to by the

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

That could be attacked as well. Then we will have something to tell that an entry exists for the table that tells that roas exists. :) What we probably need need is something that flags that a Certificate or a ROA has disappeared in the last X time. Then as operator we could take

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

Speaking as regular ol' member >That all depends on the policy undertaken by each specific provider, >doesn't it? How can you tell the difference between a route with no ROA >because the registry has decertified, and a route with no ROA simply >because one hasn't ever been created? To an ISP who

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

> What we probably need need is something that flags that a Certificate > or a ROA has disappeared in the last X time. Then as operator we could > take the action to decide if this was an attack or a valid revocation. That is probably a good idea... But since the ROAs are time based themsel

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On 3/20/13 4:41 PM, "Russ White" wrote: > >> What we probably need need is something that flags that a Certificate >> or a ROA has disappeared in the last X time. Then as operator we could >> take the action to decide if this was an attack or a valid revocation. > >That is probably a good i

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Mar 20, 2013, at 2:26 PM, Russ White wrote: >> I never argued with addressing the risks that might be posed; I was pointing >> out that the risk does not equate (on its own) with a reachability event, as >> alluded to by the paper. > > That all depends on the policy undertaken by each speci

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On 20/03/2013 17:41, Russ White wrote: > >> What we probably need need is something that flags that a Certificate >> or a ROA has disappeared in the last X time. Then as operator we could >> take the action to decide if this was an attack or a valid revocation. > > That is probably a good

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

> On 20/03/2013 17:41, Russ White wrote: > > > >>What we probably need need is something that flags that a > >> Certificate or a ROA has disappeared in the last X time. Then as > >> operator we could take the action to decide if this was an attack or a > >> valid > revocation. > > > > That is

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On 20/03/2013 20:00, Borchert, Oliver wrote: >> On 20/03/2013 17:41, Russ White wrote: >>> What we probably need need is something that flags that a Certificate or a ROA has disappeared in the last X time. Then as operator we could take the action to decide if this was an attack

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Mar 20, 2013, at 2:35 PM, "Murphy, Sandra" wrote: > Speaking as regular ol' member > >> That all depends on the policy undertaken by each specific provider, >> doesn't it? How can you tell the difference between a route with no ROA >> because the registry has decertified, and a route with no

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

aside from sharon, who is at bu, having gotten her degree at princeton, how did it get in the $subject? randy, who is not learning anything else new from this rinse repeat ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Mar 21, 2013, at 8:36 AM, Randy Bush wrote: > randy, who is not learning anything else new from this rinse repeat So, you're stating that operator input wrt impacts the RPKI will have on their networks is not useful to SIDR? OK, got it. -shane __

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

>> randy, who is not learning anything else new from this rinse repeat > So, you're stating that operator input wrt impacts the RPKI will have > on their networks is not useful to SIDR? OK, got it. no. i am saying nobody seems to be saying anything that has not already been said. but if you're

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

>> randy, who is not learning anything else new from this rinse repeat >So, you're stating that operator input wrt impacts the RPKI will have on their >networks is not useful to >SIDR? OK, got it. Randy said "nothing new", not "nothing". --Sandy, speaking as regular ol' member. _

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

Thanks for the interest in our work. We wanted to clarify a few points: -- We have a technical report, which contains motivation and details that the slide deck does not. See http://www.cs.bu.edu/~goldbe/papers/RPKImanip.pdf -- As we point out in the paper (and as John Curran, Carlos, and others

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Mar 21, 2013, at 12:48 PM, Sharon Goldberg wrote: > Thanks for the interest in our work. We wanted to clarify a few points: > > -- We have a technical report, which contains motivation and details > that the slide deck does not. See > http://www.cs.bu.edu/~goldbe/papers/RPKImanip.pdf Sharon

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Mar 20, 2013, at 7:32 PM, Arturo Servin wrote: > > > On 20/03/2013 20:00, Borchert, Oliver wrote: >> But what does the alert tell me? >> What if one is multi homed, uses two ROAs then switches to be single homed >> and revokes the second ROA. In this case the owner revoked the ROA and

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

Sharon, -- 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 t

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

> 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. thanks to shane for w

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 > > resource holder should monitor his/her RPKI pub point to detect any action > > th

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Apr 1, 2013, at 2:03 PM, Danny McPherson wrote: > 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

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 t

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Apr 1, 2013, at 7:24 PM, Danny McPherson wrote: > 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 hav

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 a

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 t

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 >> som

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 fil

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Apr 2, 2013, at 9:58 AM, Danny McPherson wrote: > 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 tho

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 ar

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 i

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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. W

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 a

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 ref

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 "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 o

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

On Apr 2, 2013, at 2:45 PM, John Curran wrote: > 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 "shop >> around" as per the above, to mitigate one or more of the concerns that I've >> illustrated above? Hint: given th

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 function > still remains an attractive 'target' for outside parties to (try to) exert > pressure and

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 inten

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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. Ultimate

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

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 mor