Mozilla Uses RPKI

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.