At the RIPE 70 meeting being held in the Okura Hotel in Amsterdam, a “Birds of a Feather” or BoF session was held to discuss the problem of our disjoint Internet Routing Registries (IRR).
IRR are used by different and disparate parts of the global BGP routing community to understand what routes should be seen in the Internet, and what providers are originating which prefixes. This is achieved by using a notation called RPSL, which is well specified, but complicated and somewhat old. It pre-dates the emerging PKI secured statements about routing and they do (in some ways) say slightly different things. But what emerged from the conversation in this BoF is that there are opportunities to develop closer relationships between these data sources, and the tools which consume them.
One of the major problems highlighted in the BoF was the existence of a necessary “hack” in the RIPE NCC IRR database, which permits out of region resources to be included in their routing statements when useful for RIPE region members. This is logistically useful for them, but creates problems for other regions where the resources actually are managed and has been exploited by spammers to “pop up” temporary announcements in BGP of the prefix behind an illegal ASN, and then go silent again.
Another problem of note is the need for address holders in regions like APNIC, who typically do not have an ASN, to contact the ASN holder and both approve the creation of their route: object. If the resources lie in different RIR regions, this can prove almost impossible and drives the address holder to IRDB, the independent (but un-authenticated) service. This problem is less visible in the RIPE region because of a high density of ASN holdings by individual address holders; far more of them get both an ASN and IP range in the RIPE region.
If you have good quality signed data about prefix Origination in a ROA, it seems sensible to use it as a strong signal of intent. If you compare this to badly secured or sometimes un-secured statements of intent in the global IRR framework (IRDB for instance, does not relate in any way to the RIR registered resource holdings, there is no formalism to confirm ownership of resources to be used in IRDB) there is no real comparison: a ROA is provably what the prefix holder wants.
The RIPE NCC has recently updated their RPKI validation tools to automatically generate route: object format data in respect of ROA seen in the global RPKI, and this is being considered for wider use by those who consume both sources of data.
Andy Newton from ARIN has demonstrated how the RDAP protocol (a replacement for WHOIS which uses JSON notation and has been covered in the APNIC blog) could be extended to cover some of the RPSL data and provide machine-readable, trustable data about each RIRs prefixes and which origination the holder wishes to announce.
Job Snijders discussed four alternatives to try and federate the space of ‘mainainers’ who have authority over the objects seen in RPSL, across the RIRs. There is no clear sense which of the various choices works best, but at least the community is talking. The problem is that there are architectural design constraints in the database behind WHOIS (and especially RIPE WHOIS) that may conflict with what we need and want in the world of routing configuration. There may not be a good solution to a complicated distributed-data problem.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.