A few weeks ago, Mozilla started to use RPKI+ROA, here is a quick introduction.
RPKI (Resource Public Key Infrastructure) 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 RIPE and probably others) is quite straightforward:
- Generate a public/private key pair,
- Communicate the public key to ARIN,
- Write a ROA (Route Origination Authorization)
- It’s basically a statement saying “I allow AS#x to advertise routes y and z”
- Sign it with our private key,
- Send the signed ROA request to ARIN,
- 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.
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 18.104.22.168/24" whois -h whois.bgpmon.net 22.214.171.124
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!