> > Nonetheless, all of the methods for whacking a ROA described in the
> > are detectable by anyone who monitors the RPKI. One might argue that
> > resource holder should monitor his/her RPKI pub point to detect any
> > 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
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
> 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?
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
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).