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
<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.)
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
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
