Recently, a lot of attention inside the ISP routing community has focussed on the awkwardness of every day data management in the ‘new world’ of IP address scarcity.
In the past, most providers of Internet services were able to obtain addresses to match their market needs, and combine them with their own Autonomous System Number (ASN) to route on the Internet. But in a IPv4 exhausted world, we’re seeing an increase in the requirement to manage routing where the holder of the IP address and the holder of the ASN routing the IP address aren’t the same entity.
This matters in context because we have a form of Routing Policy Specification Language (RPSL) data called a ‘route’ object that is used to tell the world a specific prefix is meant to originate from a specific ASN. This then permits the (semi) automatic creation of filters to admit BGP routes, which have that prefix from that origin-AS, and helps drive efficient visibility of all Internet addresses in the ‘default free zone’ of the BGP routing model.
The problem actually has two dimensions: one is that different people have to be included in the authorization processes. The other is that sometimes the people lie in different RIR regions.
Ensuring integrity of people in different RIR regions
Problem number two actually presents more issues. Having data maintained in another place means the authority to make statements about the data cannot vest inside the place you’re working in.
This causes all kinds of problems for a database, which tries to ensure ‘referential integrity’ by not permitting references to objects that can randomly be withdrawn. For example when it’s in the same database you can make database-level decisions to block deletions, updates et cetera, because you can ‘test’ the question ‘Does the object exist?’ But when the data is imported from another source, you can’t perform the same low-level database checks.
To ensure ‘referential integrity’ it becomes necessary to either import the data and ‘pretend’ it’s authoritative inside the local context or, accept a loss of referential integrity and periodically check. This is not an easy decision.
The RIPE NCC code developers made a judgement call some time ago, under the guidance of the database working group, and decided to go with data importation: they provided a mechanism to import data from other RIRs, so RIPE region routing could be maintained.
Different people have to be included in the authorization processes
To return to the first problem, there is a real coordination issue even when the parties lie in the same region.
Not everyone is participating in this kind of routing management. And from time to time we have to mediate conversations between parties to get them both to consent to the creation of an object that references both an ASN holder and a different Internet address holder. Mediating these decisions is slow and sometimes just doesn’t work.
If you return to an inter-regional model, it only gets slower (time-zones) and less reliable (non-participating, language-difference, and other reasons).
Resource Public Key Infrastructure may provide simpler authentication
So now, from left field, we have a new player: Resource Public Key Infrastructure (RPKI).
RPKI is able to make strong (cryptographically secure) statements about Internet addresses and ASN, but has a different data model for the representation of origination: an object called a Route Origin Authorisation (ROA).
ROA is to all intents and purposes saying much the same thing (there are differences) but critically, only require the address holder to (cryptographically) show consent to be routed via the specified origin-AS.
In RPKI, we have a simpler one-party authentication. ISPs are now routinely using ROA data to construct filters, but alongside RPSL objects from the Internet Routing Registries (IRR) using two-party authentication. In the case of the RIPE NCC data, objects imported from other regions under a well-known maintainer, in order to keep referential integrity goals in the database constraints.
It’s time for a simpler model
It’s time to discuss how we can move to a more consistent model of authorization in both spaces.
The conversation is happening primarily on the RIPE Regions ‘db-wg’ and ‘routing-wg’ lists, and so far appears to be heading in a useful direction under the tutelage of Job Snijders and Rob Evans (amongst others) who believe in simple, systematic changes over time to make things better.
One useful outcome is that recently the APNIC Hostmaster/Helpdesk teams realized they were increasingly caught in the problems of mediating these dual-authorization requests, and wanted to help improve service turn-around times. Their way out was to allow the address holder, to authorize the route object, and then have it made by APNIC staff on their behalf using override permissions. The ASN holder is contacted to inform them an object has been made and enabling them to request withdrawal of the object if it is not acceptable.To date, this has been remarkably well received with no complaints from the community, and APNIC is exploring if it can automate the production of these objects from within the Portal, as well as manage any withdraw requests efficiently the same way.
RIPE Region routing discussions are now considering the model, and observing that routing practices are slightly different in each region, it’s possible this approach can be applied in their context too.
There are of course risks, including the ability to ‘swamp’ the information management systems with mass creations of objects. But there is an observable risk of this anyway under the current open-maintainer model of importing data from other regions. Also other well known exploits of this loophole have permitted a high volume of incorrect routing to go un-noticed and under the wire, increasing annoyance in the wider community (pop-up routing announcements being used by some SPAM sources for instance).
In the long term, we need significantly stronger models of routing information management in the light of both more people in the system holding Internet addresses (loss of mutual trust, increases in accidental routing mis-configuration, tensions around misuse of resources) and increased risks of loss of integrity in routing. Routing Security is complex and in part will depend on external data sources like RPSL (for router configuration, filter management, and other purposes) as well as RPKI and cryptographically strong statements about addresses.
Let’s hope we can continue the conversation, and converge on a better, simpler routing management model.
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.