You are here: Home > Publications > RIPE Labs > Mirjam Kühne > Mozilla Uses RPKI
Content by this author

Mozilla Uses RPKI

Mirjam Kühne — 16 Jan 2013
A few weeks ago, Mozilla started to use RPKI (Resource Public Key Infrastructure) and ROAs (Route Origin Authorization). Here is a quick introduction.

Note: This article has initially been published on the Mozilla Blog and is republished here with the permission of the author.

RPKI is a first step to secure BGP (the routing protocol used on the Internet), it allows to certify (and verify) that a prefix is advertised by the good AS (in other words that an IP points to its legitimate owner) in order to prevent prefix hijacking (usually misconfiguration but can also be used in attacks) like the PakistanTelecom/Youtube story .

Based on that information (route valid/invalid/unknown) the router can act as configured, which is usually to lower the invalid route’s priority so the genuine route is used (so it doesn’t break anything if it’s miss-configured/expired).

Like DNSSEC, RPKI is made of 2 parts, the signing and the verification . The former is possible for us through ARIN (our RIR) the later is possible with Juniper since JunOS v12.2.

How it works (in our case but it seams to be similar with the RIPE NCC and probably others) is quite straightforward:

  1. Generate a public/private key pair,
  2. Communicate the public key to ARIN,
  3. Write a ROA (Route Origination Authorization)
    • It’s basically a statement saying “I allow AS#x to advertise routes y and z”
  4. Sign it with our private key,
  5. Send the signed ROA request to ARIN,
  6. If everything is correct, ARIN will publish this ROA to its repository, publicly available to any validator

Steps 3 to 5 have to be done for each ASN, and before the ROAs expire.
Steps 2 to 6 can be done directly through ARIN’s website (step 4 is done on the client side using JavaScript).

By doing that, any entities validating the routes they receive will not (or less) be impacted if another AS advertises a prefix the same size or smaller than ours.

Probably latter this year, we will deploy the validator, which is made of 2 devices, the router and the validator itself. To not overload the router, the validator (called RTR server) is in charge of downloading the ROAs located in the RIRs’ repositories and telling the router (RTR client) if an AS has the right to advertises the route. Then, as said earlier the router decides what to do. That validator is usually a regular server installed in the same POP as the router.

To continue with the comparison with DNSSEC, right now we are signing our DNS zones, but our own name-servers aren’t validating DNSSEC, while Comcast’s do.

You can easily check the status of a prefix using whois, for instance:

  whois -h " --roa 53371"
whois -h

The returned code will be one of the following:

  0 - ROA correct
1 - No ROA found
2 - ROA incorrect - will tell you what the error is

It’s so easy that nobody with a RIR account has a valid excuse to not start using it!


Note from the Editor: The steps above show how this works in the ARIN environment.  On the RIPE NCC web site you can find a short tutorial that describes how to manage ROAs in the RIPE NCC service region.


Jared says:
16 Jan, 2013 02:02 PM
What I have experienced is that even tech savvy folks have issues getting pki correct. It would be helpful if you gave the entire chain of events and commands (eg: OpenSSL arguments etc) to demonstrate how "simple" it is, along with the configlet from junos showing how to take your static aggregate hold-down routes and tie those to your ROA.
Alex Band says:
16 Jan, 2013 02:19 PM
You can find example config on how to set up your Cisco and Juniper routers with RPKI here:
XioNoX says:
17 Jan, 2013 09:14 AM
The chain of events is already above, the commands (it's really only openssl, webapp and then whois to verify).
The openssl commands are well explained there:[…]/faq.html#keypairgeneration
Which should be the (quite) same process with RIPE.

I also didn't have to look at the routers, as our public IP allocations are documented well enough.
Alex Band says:
19 Jan, 2013 09:23 AM
The ARIN RPKI system is the only one that has kind of OpenSSL key signing to create ROAs. RIPE NCC members who would like to create ROAs just need to have the appropriate rights, as described here:
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.