How accurate are the Internet Route Registries (IRR)

Many service providers use an IRR to register their routes and to create BGP filters. These filters define what they will accept from customers or peers.  This is considered a good practice, as it will prevent accidental leaks. However, using an IRR to build your filters is only useful if the registries are complete. You probably have heard people saying that the IRR is incomplete and therefore useless. The question remains, how incomplete is it?

What is an IRR
The Internet route registry allows you to document a number of things about your network in a predefined format called RPSL. Common things to register are, your routing policies, what do you announce to who? And which prefixes are you originating and from which origin AS.

In theory this is a wonderful idea, but as with many things in life ,day-to-day practice is a bit different.  If not everyone registers their routes in an IRR there’s no way of verifying if this is a valid announcement or not. After all it could just be that the origin AS announcing this prefix is not using the IRR the register their routes.

How to use the IRR
Some providers I work with such as Geant and Canarie are very strict in the IRR usage. If you don’t register your route, they will not accept it.  Simple as that!

Since a few months BGPmon.net has support for IRR as well. Examples are the auto detect feature that will automatically detects all the prefixes for your Origin AS and indicates if there’s a valid route object or not. Another example of IRR usage can be found in the hijack detection feature. BGPmon.net will classify each hijack either as a Code10 or Code11 alarm. Depending on whether theirs is a valid route object for this announcement or not. The usefulness of these features is largely depending on the accuracy of the IRR databases.  So I decided to try to quantify the accuracy of the IRR.

How accurate is the IRR
BGPmon retrieves a local copy of “all well known” [1] IRR databases for analyses.  I use this data to determine the accuracy of the IRR data.  For each prefix and origin AS in the global routing table it was checked if a valid route object exist. Meaning, a route object for this prefix and this origin AS.  Let’s take a look at the prefix 142.90.0.0/16. This prefix is announced by AS271. For this IRR check to succeed a route object such as below has to exist

route:        142.90.0.0/16
descr:        Tri-University Meson Facility (TRIUMF)
origin:       AS271
notify:       nmc@BC.net
mnt-by:       BCNET-BC-MNT
changed:      bofh@BC.net 20090102
source:       bcnet

More specifics and aggregates.
During this analysis I checked for both exact matches as well as a possible less specific (aggregate) that covered the prefix.
In my experience, all our upstreams always required all the prefixes we wanted to announce to be explicitly defined as a route object.  More specifics are not accepted unless there’s an exact route object.  I wonder how your upstreams are doing this?

The result

valid route object (exact routes) (Green = high score (good), Red = low score (bad))

As it turns out 46% of all the prefixes in the routing table today have a valid route object. This means that if everybody would use strict IRR filtering, the way it is done by for example Geant and Canarie,  54% of the prefixes on the Internet would be unreachable, that’s 153685 prefixes. If we allow more specific as well, 62 % of all prefixes have a valid route object.

I also distinguished the result on a per country basis, the result can be found below. And in the images. The images represent how many route objects were found for each prefix on a per country basis. Green means good, yellow medium and red means bad.
In this map it’s clearly visible that some countries score better than others. However, it might be that this analysis did not take into account an IRR server [1]  used in that region or country.

valid route object (including aggregates) (Green = high score (good), Red = low score (bad))

Raw data results:
For those interested in a more detailed result, please see these files.

• Per country result (exact matches)
• Per country result (exact or aggregate matches)

Curious how accurate the IRR information for your prefixes are? Just search for your AS in the text files below.

• Prefixes that did not have an exact route object
• Prefixes that not have an exact route object or an aggregate with a correct route object.

What does all this mean?
It means what many already knew, the IRR is incomplete.  In this blog post I tried to quantify this and presented you some numbers, these might be as expected or shocking. The fact however is, that if we ever want to do proper filtering based on route-objects or preferably ROA’s, we have a whole lot of catching up to do.

For those interested in this subject, Renesys did a similar analysis here.

Disclaimer & data sources
The check only examined route-objects. Route objects from the IRR registries below were examined.
RIPE RIS was used as a data source for the rib files. Only IPv4 prefixes were included.
MaxMind geo IP library was used to determine country information.

[1] Used IRR registries:
ripe, altdb, aoltw, apnic, arin, bcnet, bell, deru, digitalrealm,easynet, ebit, epoch, gt, gts,
gw, host, jpirr, level3, mto, nestegg, nttcom, openface, ottix, panix, radb, reach, retina,
rgnet, risq, rogers, savvis, wvfiber