RPKI, NZNOG 2014

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.

Improved Slide deck

The state of NZ RPKI deployment, February 2014

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)

Auckland Peering Exchange RPKI Origin Validation Status (February 2014)

Wellington Internet 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)

Christchurch Internet Exchange RPKI Origin Validation Status (February 2014)

Typical NZ "Domestic" Transit RPKI Origin Validation Status (February 2014)

Typical NZ

Methodology

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 :)

Raw IX path data

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".

Sample configuration information

Setting up the "relying party" cache server

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):

aptitude install rpki-rp

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.

Configuring Junos to validate origin data

The configuration in Junos is quite straight forward. The subset of the routing-options hierarchy required is simply:

routing-options { validation { group lab { /* rpki-validator.lab.hotplate.co.nz */ session 192.0.2.1 { port 43779; } } } }

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:

policy-statement peer-to-validate-in { term valid-origin { from { protocol bgp; validation-database valid; /* checks the validation state */ } then { validation-state valid; /* re-writes the validation state */ community add rpki-origin-valid; accept; } } term invalid-origin { from { protocol bgp; validation-database invalid; } then { validation-state invalid; community add rpki-origin-invalid; accept; } } term unknown-origin-validity { from protocol bgp; /* catch-all for any remaining routes */ then { validation-state unknown; community add rpki-origin-unvalidated; accept; } } }

Further resources

I will be updating this list with further resources I have squirreled away at some point.


Unleash