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

From: Sharon Goldberg <[email-masked]>
Date: Mon, 1 Apr 2013 12:17:45 -0400

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

---

From: Danny McPherson <[email-masked]>
Date: Mon, 01 Apr 2013 12:03:32 -0600

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: "Osterweil, Eric" <[email-masked]>
Date: Mon, 1 Apr 2013 14:57:24 -0400

On Apr 1, 2013, at 12:17 PM, Sharon Goldberg <[email-masked]> wrote:

<snip>

> 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=194.126.136.0/21-24&r=6254

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: John Curran <[email-masked]>
Date: Mon, 1 Apr 2013 20:37:31 +0000

On Apr 1, 2013, at 2:03 PM, Danny McPherson <[email-masked]> wrote:

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

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

FYI,
/John

John Curran
President and CEO
ARIN

---

From: Danny McPherson <[email-masked]>
Date: Mon, 01 Apr 2013 17:24:00 -0600

On 2013-04-01 14:37, John Curran wrote:

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

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

---

From: John Curran <[email-masked]>
Date: Tue, 2 Apr 2013 02:31:03 +0000

On Apr 1, 2013, at 7:24 PM, Danny McPherson <[email-masked]> wrote:

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

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 
needs (as opposed to domain names that serve single business interests) 

> 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 ;-)

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

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); from your report, it seems that 
they've gotten the message so far... ;-)

FYI,
/John
 
John Curran
President and CEO
ARIN

---

From: Shane Amante <[email-masked]>
Date: Mon, 1 Apr 2013 20:36:11 -0600

On Apr 1, 2013, at 10:17 AM, Sharon Goldberg <[email-masked]> 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.
> 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:
> 
> 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

---

From: Danny McPherson <[email-masked]>
Date: Tue, 02 Apr 2013 07:53:21 -0600

On 2013-04-01 20:31, John Curran wrote:

> 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

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.

> 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: John Curran <[email-masked]>
Date: Tue, 2 Apr 2013 14:26:59 +0000

On Apr 2, 2013, at 9:53 AM, Danny McPherson <[email-masked]> 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... 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 
likely to have little impact since the routing is still there, and we don't 
seem to have any documentation suggesting to _only_ listen to routes that 
are known valid.  Loss of ROA coverage exposes one to further exploits, 
but per existing guidance it should not result in connectivity impacts 
(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 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)?

Danny, I never said "DNS takedowns are a good idea"; I said we "educate 
law enforcement about the difficulty of attempting granular actions on 
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 
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 
understanding of that potential (and the same could be said for RPKI...)

Thanks!
/John

John Curran
President and CEO
ARIN

---

From: Shane Amante <[email-masked]>
Date: Tue, 2 Apr 2013 08:53:19 -0600

John,

See below.

[--snip--]
> (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: John Curran <[email-masked]>
Date: Tue, 2 Apr 2013 15:30:29 +0000

On Apr 2, 2013, at 10:53 AM, Shane Amante <[email-masked]>
 wrote:
> 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.

That's definitely a possible long-term outcome.

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

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.

FYI,
/John

---

From: Danny McPherson <[email-masked]>
Date: Tue, 02 Apr 2013 09:58:29 -0600

> given IP address block) via one handful of court orders directed to 

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 McPherson <[email-masked]>
Date: Tue, 02 Apr 2013 10:02:58 -0600

On 2013-04-02 08:26, John Curran wrote:
> 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 Amante <[email-masked]>
Date: Tue, 2 Apr 2013 10:27:02 -0600

On Apr 2, 2013, at 9:58 AM, Danny McPherson <[email-masked]> wrote:
> Assuming those backbones operate within jurisdictional or MLAT reach, as opposed to where an RIR falls jurisdictional.
> 

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: John Curran <[email-masked]>
Date: Tue, 2 Apr 2013 17:22:06 +0000

> 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 do…

That would suggest that monitoring and alerting aspects of these services 
are indeed important, but that doesn't appear to be materially different 
than the risks associated with relying on third-party filter lists, anti-
spam blocklists, or IRR data for delivering reliable services today.

/John

---

From: Stephen Kent <[email-masked]>
Date: Tue, 02 Apr 2013 13:59:07 -0400

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 02 Apr 2013 14:08:07 -0400

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

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 2 Apr 2013 14:09:50 -0400

On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent <[email-masked]> wrote:

> Danny,
>
> The architecture permits overlapping allocations to accommodate transfers
> that involve address space that
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

>> As for today, the architecture permits such collisions, which I think is
>> the issue most agree is, err.. suboptimal.
>>
>> -danny
>>
>> ______________________________**_________________
>> sidr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/sidr<https://www.ietf.org/mailman/listinfo/sidr>
>>
>>
> ______________________________**_________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/sidr<https://www.ietf.org/mailman/listinfo/sidr>
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 02 Apr 2013 14:11:35 -0400

Shane,
> 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 do…
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,…
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: Stephen Kent <[email-masked]>
Date: Tue, 02 Apr 2013 14:43:33 -0400

Sharon,

...
> 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.
> > three approaches (not the preferred approach) to participating in 
> the RPKI.
>
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.

> 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/%7Egoldbe/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.)
> 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: Stephen Kent <[email-masked]>
Date: Tue, 02 Apr 2013 14:45:35 -0400

Chris,

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

Steve
-

> On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Danny,
>
>     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 <http://128.2.35.0/24> + AS28
>
> In the near-future as 128.2.35.0/24 <http://128.2.35.0/24> moves from 
> AS28 -> AS22224:
> 128.2.35.0/24 <http://128.2.35.0/24> + AS28
> 128.2.35.0/24 <http://128.2.35.0/24> + AS22224
>
> 128.2.35.0/24 <http://128.2.35.0/24> + AS22224
>
>         As for today, the architecture permits such collisions, which
>         I think is the issue most agree is, err.. suboptimal.
>
>         -danny
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Shane Amante <[email-masked]>
Date: Tue, 2 Apr 2013 12:59:48 -0600

John,

> 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 McPherson <[email-masked]>
Date: Tue, 02 Apr 2013 13:20:18 -0600

On 2013-04-02 11:59, Stephen Kent wrote:
> 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: Stephen Kent <[email-masked]>
Date: Tue, 02 Apr 2013 15:47:43 -0400

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

---

From: John Curran <[email-masked]>
Date: Tue, 2 Apr 2013 20:45:21 +0000

> 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 presen…

I'm not certain you are describing a problem in RPKI architecture for 
the working group: while there is ability to have overlap in RPKI 
(as noted for purposes such as transfers and moves), there are still
assumptions regarding regions and hierarchy in the Internet Registry 
system that make your perceived problem difficult to solve in the 
general case.  One approach (if it were really an issue) would be to 
handle it similar to the DNS with shared registry/multiple registrars
(and the registrars providing the RPKI services you seek), but that 
would not likely be a sidr (or IETF) scope work item in any case...

/John

---

From: Shane Amante <[email-masked]>
Date: Tue, 2 Apr 2013 15:59:12 -0600

On Apr 2, 2013, at 2:45 PM, John Curran <[email-masked]> wrote:
> general case.  

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 

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: John Curran <[email-masked]>
Date: Wed, 3 Apr 2013 01:49:21 +0000

> 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 outsi…

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, 
and those who are worried more about the possibility of easy 
route hijacking will use it... (like many other security-related 
capabilities in the Internet, the deployment choice is left to 
each network.)

/John

---

From: Shane Amante <[email-masked]>
Date: Tue, 2 Apr 2013 20:25:36 -0600

Steve,

Thanks for your response.  Please see below.

On Apr 2, 2013, at 12:08 PM, Stephen Kent <[email-masked]> wrote:
> 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

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

-shane

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 2 Apr 2013 22:31:28 -0400

On Tue, Apr 2, 2013 at 10:25 PM, Shane Amante <[email-masked]> 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?

---

From: Stephen Kent <[email-masked]>
Date: Wed, 03 Apr 2013 11:06:35 -0400

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 
> 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.
> will include these types of detail.
yes, it does.
> 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