Mozilla Uses RPKI

Mirjam Kühne — Jan 16, 2013 01:40 PM
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 whois.bgpmon.net " --roa 53371 63.245.217.105/24"
whois -h whois.bgpmon.net 63.245.209.0

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.

4 Comments

Jared
Jared says:
Jan 16, 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
Alex Band says:
Jan 16, 2013 02:19 PM
You can find example config on how to set up your Cisco and Juniper routers with RPKI here: http://www.ripe.net/certification/router-configuration
XioNoX
XioNoX says:
Jan 17, 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: https://www.arin.net/[…]/faq.html#keypairgeneration
and
https://www.arin.net/[…]/faq.html#roarequestsigning
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
Alex Band says:
Jan 19, 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: http://ripe.net/certification/enable
Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

Navigation
Related Items
Using RIPE Atlas Metadata to Measure NATs

As part of the user interface to the RIPE Atlas network, users can see the first and second hops ...

RIPE Atlas Fun: Map a RIPE Atlas Anchor

View maps based on RIPE Atlas traceroute measurements. Compare the maps to the ISP's description of ...

New and Improved RIPE Registry Global Resource Service

We have redesigned and improved the way we mirror other databases. We now have a method of ...

RIPE Database Joins Single Sign-On Club

With RIPE NCC Access, our single sign-on service - you log in once and can access many RIPE NCC ...

A RIPE Atlas View of Internet Meddling in Turkey

In RIPE Atlas we see latencies to Google's 8.8.8.8 DNS resolver service drop in Turkey. We expect ...

more ...