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 have noted here) a missing ROA will not necessarily make the target unreachable. That depends on the policy at relying parties. We discuss this in Section 3 of the report. For example, if a route for a prefix becomes invalid due to a missing/invalid ROA, and if everyone uses a "drop invalid" policy, that prefix would become unreachable. However, with other policies (e.g. depref invalid) the prefix may still be reachable. -- Per John Curran and others' points, we want to emphasize that a missing ROA can make a route either unknown or invalid. That depends on whether there is another ROA for a covering prefix and a different AS (see http://tools.ietf.org/html/rfc6483#section-2). -- 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. -- 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. -- We agree with the observation that watching the RPKI repositories for changes/anomalies is a good first to step to mitigating the impact of manipulations. We are working on such a system right now. More comments are welcome. Sharon, Leo, Danny, Ethan, and Kyle (At Boston University, not Princeton!) -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
