As has been discussed here many times in the past, one of the most fragile and vulnerable components of the Internet infrastructure is the global routing system. The Border Gateway Protocol (BGP) is used to exchange destination reachability information (routes) between different autonomous systems (AS) on the Internet. These routes consist of blocks of IP addresses, often referred to as prefixes, which are allocated to ISPs or end sites by RIRs (Regional Internet Registries). Beyond allocating addresses, RIRs play no actual role in the operational aspects of Internet routing. Furthermore, there has generally been no linkage between RIR allocations and Internet Routing Registry (IRR) route objects, beyond some nifty RPSS hooks RIPE provides to help ensure the integrity of the IRR they operate. The undesirable result of this is demonstrable by the ease of which routes can be hijacked on the Internet today (e.g., the YouTube and Pakistan Telecom incident).
Once an AS is allocated blocks of addresses, they often, but are by no means required to, register these addresses in an IRR, and often associate them with an originating AS and perhaps even other associated routing policy attributes (e.g., see RPSL). They may operate their own IRR, use an IRR operated by their ISP, use an IRR operated by an RIR, use other IRRs such as the RADB, or even use another ISP’s IRR. Or, use no IRR at all. A list of most operational IRRs today is available here. Some ISPs require that BGP customers register their routes in an IRR, and generate route filters for the customers based on the IRR objects associated with their customer origin and downstream autonomous systems.
Today, if inter-domain route filtering is employed at all, it’s typically done so by ISPs in the customer -> ISP direction (i.e., the red ‘X’s in the diagram above). There’s very little filtering between ISPs, and not all ISPs filter their customers based on IRR data. One of the primary reasons for this is because of the integrity of data in the IRRs, and the security of the update and internal mechanisms employed by the IRRs themselves. If anything, the use and employment of IRR data for route filtering between ISPs and customers has only deteriorated over the past decade, creating a bit of a chicken & egg problem; where the chicken is the use of the data by network operators to generate route filter policy, and the egg is the availability of trustworthy verifiable source documenting what AS is authorized to originate what routes.
Fortunately, with the SIDR work happening in the IETF, and the RIRs busily coding away to support a Resource Public Key Infrastructure (RPKI), the development of the ‘egg’ is well underway. Building upon this, proposals have been put forth in ARIN by myself and Randy Bush, and RIPE and APNIC by Randy and others, to introduce an overlay IRR with route objects generated from Route Origin Authorizations (ROAs) from the RPKI. This data can be used by networks operators as a more trustworthy source for who is authorized to originate what.
Initially, network operators can implement policies that give preference to route announcement that are verifiable within the RPKI-based IRR (the purple box in the diagram). Subsequently, preference can be given to internal databases and/or IRRs, then third-party IRRs, and then unregistered routes. Ideally, this will quickly evolve to enable more folks to filter customer routes explicitly based on IRR data, and in the near future, explicit bilateral deployment of inter-provider filtering based on trustworthy IRR data. In addition, that same data can be used to generate anti-spoofing data path filters akin to those recommended in BCP 38.