You are here: Home > Publications > RIPE Labs > Denis Walker > Out-of-Region ROUTE(6) and AUT-NUM Objects in the RIPE Database

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

Denis Walker — 09 May 2018
Contributors: Tim Bruijnzeels
There are changes being made to the way out-of-region objects are managed and represented in the RIPE Database. The following information is important to all database users.

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.

12 Comments

AHMAD says:
07 Aug, 2018 10:43 AM
HI
Dear colleague,

This email is to notify you that on Tuesday, 4 September 2018, all "mnt-routes:" attribute(s) will be removed from the following AUT-NUM object(s):


    AS48701
    AS29310


This change is due to NWI-5 (out of region ROUTE(6) and AUT-NUM objects), which the Database Working Group has asked the RIPE NCC to implement.

The AUT-NUM "mnt-routes:" maintainer is no longer needed to authenticate ROUTE(6) object creation, and so the attribute will be removed.

If you wish to be notified about references to your AUT-NUM object(s) on ROUTE(6) creation, then add a "notify:" attribute to your AUT-NUM object(s).

For more information on NWI-5, please refer to:
https://labs.ripe.net/Membe[…]bjects-in-the-ripe-database

If you have any questions, please contact us at <ripe-dbm@ripe.net>.

Kind regards,
The RIPE NCC Database Team


ME:
PLEASE Is there an effect on company and banks ?
AHMAD says:
07 Aug, 2018 10:45 AM
What is the effect of this variable.?
Awni Natsheh says:
07 Aug, 2018 03:39 PM
hi Ripe
please Is there an effect on ASN's from removed the AUT-NUM
Nathalie Trenaman says:
27 Aug, 2018 10:01 AM
Hi Ahmad and Anwi,

What will change from the 4rd of September, is that only a prefix holder can create a ROUTE or ROUTE6 object. They don't need authentication/approval from the holder of the AS number any more. This is why we will remove the "mnt-routes" attribute from AS number objects (AUT-NUM objects), because they are not needed any more. In case you have questions about your specific situation, please drop an e-mail to our Customer Services team at ripe-dbm@ripe.net
Mohammad Hassan says:
29 Aug, 2018 04:02 AM
Hi Nathalie,

We have and ASN and prefixes assigned to it.
we are advertising our prefixes locally in our country under our ASN.

would this change affect us in a way or another?

Please advise.

Best Regards!
Brian Phillips says:
01 Sep, 2018 06:42 PM
We have an AFRINIC range we are using for critical infrastructure. How will this affect us?
Is there a way we can request exclusion from this new policy? Will our providers need to change anything to continue servicing us with our Routing? We cannot have the range go down. Please advise as we wish to be sure of no impact. Our understanding is you will not permit NEW objects but remaining objects are safe, is this the case? Please clarify. We are using only ipv4.
Nathalie Trenaman says:
03 Sep, 2018 11:02 AM
Hi Brian,
It is not possible to request exclusion, but you could of course register the route object in the AFRINIC database, if you haven't done this already. The only thing we will change is the source attribute of your object to RIPE-NONAUTH. You could ask your providers if they need to update anything, as we don't know how they build their filtering policies. Most providers don't filter on the "source" attribute, in that case there is no impact. You can find the full implementation plan at: https://www.ripe.net/[…]/impact-analysis-for-nwi-5-implementation
Nathalie Trenaman says:
29 Aug, 2018 09:51 AM
Hi Mohammad,

If you have RIPE region prefixes and a RIPE region ASN and a route(6) object registered in the RIPE Database, there will be no changes for you.
If you have prefixes from LACNIC, APNIC, ARIN or AFRINIC and you create route(6) objects in the RIPE Database for any reason, you would be impacted, but you would have received an e-mail about this already.
I hope this clarifies things for you.
Gabor says:
14 Sep, 2018 02:52 PM
Hi,

Currently we have RIPE ASN with ARIN prefixes as RIPE route objects.
we are runnning our business on these ARIN prefixes in EU.

If we want to continue using ARIN prefixes in EU, what is the official way to do it? I dont believe RIPE has enough spare IP ranges to give everyone RIPE prefixes who was using other RIRs.

insted of different territories and cross authentications, why not making one global RIR? internet is global.

Regerds,
gabor
Nathalie Trenaman says:
20 Sep, 2018 09:44 AM
Hi Gabor,

Currently, everything should be working as normal for you. It was not part of this project to remove any objects from the RIPE IRR. Would it be an idea to create a ROUTE(6) object in the ARIN IRR as well, since that is the RIR where the prefix is registered?
Sascha Schwarz says:
27 Sep, 2018 03:43 PM
We have a similar Problem. We use a /16 globally which is in ARIN now. But we use subnets from it in EMEA.
So I cannot create a route object in RIPE anymore? Then the local providers will filter out that ranges.

So what is the solution?
Nathalie Trenaman says:
01 Oct, 2018 04:40 PM
Hi Sascha,
As the prefix was allocated by ARIN, I recommend you create a ROUTE(6) object in the ARIN IRR. This is the way the policy was intended by the RIPE Community. As I wrote earlier, we will currently not remove any ROUTE(6) objects from our IRR, they just have a different source attribute, so everything should be fine. If you have more questions about how to create a ROUTE(6) object with ARIN, please contact them directly.
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.