Out-of-Region ROUTE(6) and AUT-NUM Objects in the RIPE Database

Summary

A consensus has been drawn following discussions by the RIPE Database Working Group community that the Routing Registry will no longer support the creation of out-of-region route(6) and aut-num objects. Also, creation of route(6) objects will no longer need authorisation from the ASN holder. Existing out-of-region objects will have their "source:" attribute changed to “RIPE-NONAUTH” and may be subject to further discussions by the community.

Some Context

Many providers in the RIPE region require route(6) objects for the prefixes they originate, which can include prefixes that were allocated by the other Regional Internet Registries (RIRs). However, credentials can’t be provided for these resources when creating route(6) objects in the RIPE Database, as the corresponding inet(6)num objects don’t exist in this database. Several ideas for cross-registry authorisation have been proposed in the past to get these credentials from the relevant authoritative RIR Database, but a workable solution could never be reached.

Also, for a number of years route(6) objects for AFRINIC resources were being created in the RIPE Database where neither the prefix nor the authoritative ASN resources were in the RIPE Database.

Because providers continued to insist on having route(6) objects in the RIPE Database, and with no clear alternative authoritative Internet Routing Registry (IRR), it was decided that route(6) objects could continue to be created for any out-of-region prefix and/or ASN by using a well-known maintainer with a public password. By definition, authorisation by the real prefix and/or ASN holder was unverified. This has led to a number of cases where out-of-region resources were hijacked, with false route(6) objects giving the hijack the appearance of legitimacy.

It’s also possible to create an out-of-region aut-num object in the RIPE Database for any non-RIPE-issued resource by using this well-known maintainer. This allows the creation of route(6) objects where the "origin:" references an ASN that is not registered by the RIPE NCC. These out-of-region aut-num objects are confusing however, because again it’s not formally verified that they are created and maintained by the registered ASN holder. Even when they are, they may be out-of-sync with the object in the authoritative database.

Using this public MNTNER to create data in the RIPE Database gives the impression that the data has been authorised. In reality, this totally bypasses authorisation and allows anyone to create these objects. In an age where hijacking is becoming more common, this is not a good situation.

Changing Views

The situation regarding out-of-region resource objects in the RIPE Database has gone through many different stages and has several historical roots. While there were good reasons for creating this service at the time, as things have changed its continuation has become controversial. There have been many polarised discussions about this service over several years, with strong views on both sides. No consensus was possible under these circumstances, and so the service continued without change.

Recently, calls to discontinue this service have grown, while support for it has faded away. When a Last Call for comments was made in January there were calls to stop the service, but no comments arguing that it should be preserved. The co-chairs of the Database Working Group therefore declared a consensus on stopping the service.

Historical Background

In the early days of the RIPE Database, networks were trusted to document their routing policies honestly and openly, as most still do. This included ASN to ASN policy ("import:" and "export:"), as well as announcements for prefixes originated at the ASN. For this reason, the creation of route(6) objects initially only needed to be authorised by the holder of the aut-num object in the "origin:" attribute [RFC 1786, March 1995 and RIPE-120, Oct 1994].

However, it was concluded some time later that prefix holders MUST provide an authorisation for route(6) objects as well, because without this it would be trivial for an ASN to hijack any prefix [Section 9.4 of RFC 2725, December 1999].

This complicated the creation of route(6) objects, especially in cases where a database user could not authorise for both the prefix and the ASN. Initially the solution in the RIPE Database required that credentials for both were provided at the time of creation of a route(6) object, for example by supplying a password for two maintainers. To partially get around this, the “mnt-routes:” attribute was added to aut-num and inet(6)num objects. This allowed one party to add the other party’s mntnr object to their resource object. Then the route(6) object could be created by just one of the parties.

More recently, there was the introduction of “pending” route(6) object creation. This allows either the prefix or ASN holder to initiate the creation of a route(6) object - the other resource holder then needs to confirm the object creation within a week before the object is finalised.

In the Resource Public Key Infrastructure (RPKI), Route Origin Authorisation (ROA) objects fill a similar function to route(6) objects [RFC 6482, February 2012]. It’s interesting to note that here the authorisation by the ASN holder is no longer required. This is because the ASN can simply decide not to announce a prefix that it doesn’t want to originate. This greatly simplifies the authorisation model.

The issue was further complicated by the historical structure of the RIRs and their services. Before AFRINIC was set up in 2005, half of the African Internet number resources were registered in the RIPE Database. Because AFRINIC did not initially offer a routing registry after it became an RIR, all route(6) objects for a large part of the African address space remained in the RIPE Database. Aut-num objects ended up split between the two databases, with the authoritative registration data in the AFRINIC Database and routing policy information in the RIPE Database. It remained this way until the start of the AFRINIC IRR homing project a few years ago.

This service was not only used for AFRINIC data. Resources from other regions were also duplicated in the RIPE Database, with route(6) objects being created without proper authorisation. This duplication and overlapping data with no certainty of what was authoritative was not a good situation.

The Way Forward: No New Unauthorised ROUTE(6) or AUT-NUM Objects

The community consensus is that it should no longer be allowed to create new route(6) or aut-num objects in the RIPE Database where authorisation cannot be properly verified using authoritative resource objects in the RIPE Database.

As a first step, it was decided that the authorisation by the holder of the aut-num object referenced in the "origin:" attribute of route(6) objects will no longer be required when creating route(6) objects. Experience with ROAs has shown that this authorisation adds little value. Moreover, this simplification has distinct advantages:

• It allows for an unambiguous definition of what constitutes an out-of-region route(6) object: if the prefix is not registered in the RIPE region, the route(6) object itself is considered out-of-region.
• It will no longer be necessary to create out-of-region aut-num objects if a RIPE region prefix holder wishes to authorise an out-of-region ASN.

The well-known mntner object "RIPE-NCC-RPSL-MNT" will be removed from the RIPE Database, after a clean-up of objects that reference it wrongly. The public password can initially be locked to prevent any further use. Furthermore, the "mnt-routes:" attributes will be removed from the current placeholder inet(6)num objects that exist in the RIPE Database to mark out-of-region ranges, as well as the "mnt-lower:" attribute on placeholder AS-BLOCK objects marking out-of-region ASN ranges.

Changes to the AUT-NUM Object

Because aut-num objects will no longer play a role in authorising route(6) object creation, the "mnt-routes:" attribute will be deprecated. The RIPE NCC will perform a one-time clean-up and remove this attribute where present. Resource holders for these objects will receive a notification of this change with an explanation of the motivation, referencing this article.

Existing Out-Of-Region Objects

Because current operations in many networks depend on existing out-of-region route(6) and aut-num objects, they will be retained for now. However, the "source:" attribute of these objects will be modified to "RIPE-NONAUTH" instead of "RIPE".

Queries that do not specify any source parameter will get both "source: RIPE" and "source: RIPE-NONAUTH" objects in their results. It’s believed that this will have the lowest impact on existing operations that use out-of-region objects in filtering.

Operators can limit their queries to "source: RIPE" only, or they can filter the results locally based on this attribute. This allows operators to disregard out-of-region route(6) objects (as their authorisation is questionable) or treat them with a lower preference.

All existing out-of-region resource objects in the RIPE Database can continue to be modified by their maintainers to keep the data up-to-date. They can also be deleted when they are no longer needed.

Where Do We Go from Here?

Over the longer term, the community, through the Database and Routing Working Groups will need to decide what the best course of action is regarding the existing out-of-region objects. Some voices have expressed that all of these objects should eventually be deleted. However, it seems that the current consensus is to do this in steps.

The first steps, as outlined above, are to mark existing out-of-region objects, and to prevent the creation of new ones. This may encourage operators to use more authoritative sources and delete some existing objects. In time, a re-evaluation can be done to see whether the remaining out-of-region objects in the RIPE Database are still needed. Any clean-up is best done by the resource holders who know what data is authoritative and up-to-date.

The RIPE NCC is currently working on an implementation plan that will be shared with the community in due course. There will also be a brief presentation on this implementation in the Database WG at RIPE 76 on 16 May 2018.