Behind the Scenes of RPKI

Best practices for making RPKI resilient to failures and attacks recommend using multiple URLs and certificates for publication points as well as multiple relying parties. We find that these recommendations are already supported by 63% of the ASes with RPKI.
In this work we explore the dependency of the RPKI deployments on their DNS components. We find that the resilience of RPKI can be subverted through DNS. We identify two key factors.
First, we find that 42.8% of the ASes with multiple relying parties use a single resolver for looking up the RPKI publication points and the DNS resolvers of 82.9% of the relying parties are all located on a single AS. Both introduce a single point of failure. Second, we also find problems with DNSSEC deployments: more than 24% of the resolvers in RPKI experience failures with signed DNS responses and as a result cannot locate the RPKI publication points and cannot validate RPKI, and 60% of the resolvers that support DNSSEC do not validate records signed with new algorithms, accepting responses also with invalid signatures.
We experimentally find that adversaries can disable RPKI in 56.7% of the ASes that have vulnerable DNS components. Our simulations show that disabling RPKI exposes ASes to prefix hijack attacks. Our work demonstrates, that resilience of systems, like RPKI, cannot be achieved in isolation due to complex inter-dependencies with other systems.