At NZNOG 2014 I presented a talk entitled "RPKI", which covered my experiences deploying an RPKI relying party cache server as well as some information about how RPKI works, what RPKI is, how to publish and validate ROAs and why all of this is important. I also promised to share some research I'd conducted in to the state of RPKI deployment within New Zealand.
Unfortunately the research was not made fully available during the talk, so I present here an updated and complete copy of the data, as well as a fixed slide deck and some further reading for interested parties.
If you'd like to play with validating some prefixes by hand my test relying party cache server has a swanky web interface for making individual queries against the "real world" dataset. Some of the information from this page is also duplicated there.
These charts show what portion of the routes at each location fall in to which RPKI Origin Validation category. For the IXes the route data was obtained directly from the IX route servers, so contains all routes, not just the "best" route to each prefix.
|Auckland Peering Exchange RPKI Origin Validation Status (February 2014)||Wellington Internet Exchange RPKI Origin Validation Status (February 2014)
|Christchurch Internet Exchange RPKI Origin Validation Status (February 2014)||Typical NZ "Domestic" Transit RPKI Origin Validation Status (February 2014)
The complete set of routes learned by the NZIX route servers was dumped (by abusing their Looking Glass tool, which is a bit iffy at the moment) and converted in to a set of JSON files for easier later consumption.
Using the relying party cache server I had set up for testing these datasets were then validating against the global RPKI database. To do this rtr-origin from rpki.net was used in its "toy client" mode to produce an sqlite database of ROA data, and a python script turned this database in to a set of ipaddr-py objects for easier matching.
The code which was used to perform the matching is the same code used to drive the cache query demo on the Hotplate test RP server webpage, so if you suspect bugs in my findings you should be able to replicate them there first :)
The path data from the surveyed IXes is presented below. The APE data may be partially incomplete as the Looking Glass is currently misbehaving. I have used some trickery to try and work around the broken bits, so hopefully it's close to a full dataset. This data was last refreshed on 2014-02-16.
The "readable" validation output for these three datasets is also available should you wish to e.g. see "why" a particular prefix was marked as "invalid".
This is documented on rpki.net, though it is worth noting that if you only need the RP functionality, it suffices to just install the rpki-rp package as root (use sudo or su as appropriate to your environment):
In production this may not be secure enough! I would hesitate to suggest running the communication between your RP and your routers in plaintext. At the very least I would recommend running this traffic over some kind of trusted management network, and configuring something like ipsec would be a good idea.
The configuration in Junos is quite straight forward. The subset of the routing-options hierarchy required is simply:
Where 192.0.2.1 should of course be replaced by an IP address or hostname for your own relying party cache server.
Once enabled this provides a few new extra policy match options in Junos, the most interesting of which are probably:
I will be updating this list with further resources I have squirreled away at some point.