Dear colleagues, we are glad to inform you that our team has finished integration with IRR data sources and ROA records. It should significantly increase the quality of hijacks detection, plus improve transparency of what is happening to route objects in different registries.
The primary task of any Regional Internet Registry or RIR (and we have five of them: RIPE, APNIC, ARIN, AFRINIC, LACNIC) is the allocation of AS numbers and IP-address space among its members. It includes not only general allocation, but also registrations of change, which is quite important in the era of IPv4 transfers. RIR may run Internet Routing Registry databases (IRRs) for various objects - route objects, different set objects, contacts, etc. However, all this activity is executed by each RIR independently, and after 20 years it resulted in almost mutual incompatibility between policies and objects in different IRRs.
This independence proved to have significant hidden cost. In this blog, a few times we discussed the importance of building IRR filters ([1], [2], [3]). But how to build those filters correctly if there is no authorization for route objects creation? Moreover, there is the LACNIC that does not provide support to retrieve route objects from its service region! Such situation opens the door for private registries, like RADB, NTTCOM, Level3, and others. These registries have no limitation (like service region), but also, there is no authorization, and in a long-term, they are increasing the amount of outdated and incorrect objects.
To address this problem, we created a route object aggregator that uses all available data sources. With its help, we created a wizard on the «Prefixes» page that shows the existence of a proper route object for an ISP that originates selected prefix. Besides, all overlapping objects with corresponding data source are shown in the popup:
Another improvement of this release is the integration with ROA records. A ROA record represents a triplet (prefix, ASN, max_length). Unlike route objects, ROAs are unique and are cryptographically signed by IP-address space holder. So, in the future, they may become a reliable data source compared to route objects, but it is not true so far:
According to our study, only ~10% of globally visible prefixes have signed ROAs, and among these, every tenth prefix is not passing a validation check. The situation would be changing in near future as huge IXes have agreed to start dropping invalid routes at their route servers. So, we encourage all our users to sign their address space, and check that all corresponding ROAs are up to date. To support this initiative, we also integrated ROA validation check in the «Prefixes» page.
At the moment we cannot entirely rely on IRR data or ROA records. That’s why while solving hijack detection problem we decided to use both sources. Previously, we had MOAS page, which was showing all overlapping address space announced by different ASNs. It was useful, but it also had a lot of false positives. To remove those false positive alarms, we started using following logic to verify each announce:
- If the outcome of ROA validation procedure is «valid», the procedure halts with «valid»;
- If the outcome of ROA validation procedure is «unknown» and a valid route object exists, the procedure halts with «valid»;
- Otherwise, the procedure halts with an outcome «invalid».
With this procedure, we were able to mark with «valid» and «invalid» both sides of MOAS conflict, thus splitting it into an affected hijack, created hijacks and legitimate conflicts. Please check the «Hijack» page for your ASN and if you see a false positive there - you should know whom to blame. In this case, we encourage you to hurry up and sign your address space with ROA records, or at least create correct route objects.