>> Just to understand the "complexity" attacker's purpose, what is he >> trying to accomplish by changing his prefix's origination AS (and hence ROA) >frequently? >> Do you mean that he can bloat the CRL into something huge by >> repeatedly issuing many EE certs and their revocations? >> > there are different angles. Introducing a high ROA churn may not only harm > the >RP but also the router (heavy operations on the prefix table ...). Overall >purpose >would be to create worst-case load on data structures. We started some >analysis on this but didn't finish. > > My main point was that "such events occur rarely" under normal conditions. >But any owner of a prefix is free to create/update/delete ROAs on much smaller >time scale. Or did you mean the (configured) cache update time with "rarely"? >
OK, thanks for the clarification. The deterrence/defense against a prefix owner maliciously creating thousands of ROAs to conduct some kind of DOS attack would be: 1. He probably has RPKI repository service with an ISP. The ISP would detect the suspicious nature of it, and would limit him in some way. 2. If he maintains an RPKI repository himself, his repository's reputation will suffer and will be likely soon be black listed for having excessive/suspicious quantity of RPKI objects, e.g., way too may ROAs signed by the same prefix cert (key). (The operator community would want to maintain a "repository reputation database".) 3. The RPKI repositories/servers can set a generous threshold on # ROAs per prefix, and reject all the ROAs for that prefix if the threshold is exceeded. 4. Any fictitious ROAs with unregistered/unallocated ASNs will get rejected, so he could only perhaps register at most 50,000 or so ROAs (one for each legit AS in the universe). I think one bad guy creating 50,000 ROAs will not overwhelm the global RPKI system. But before he gets there, the other mechanisms (#1, #2, #3 above) will limit him anyway. 5. I think you would be right in saying that "cache update time" or RPKI propagation delay will limit him if the concern is about how frequently he propagates the ROAs. Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
