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