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.
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.
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.
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.
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.
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
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/Members/denis/out-of-region-route-6-and-aut-num-objects-in-the-ripe-database If you have any questions, please contact us at <firstname.lastname@example.org>. Kind regards, The RIPE NCC Database Team ME: PLEASE Is there an effect on company and banks ?
What is the effect of this variable.?
Awni Natsheh •
hi Ripe please Is there an effect on ASN's from removed the AUT-NUM
Nathalie Trenaman •
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 email@example.com
Hide 3 replies
Mohammad Hassan •
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 •
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.
Hide one reply
Nathalie Trenaman •
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/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation
Nathalie Trenaman •
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.
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 •
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 •
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 •
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.
Hi Denis walker ...long time not see you..hope you are ok. Did u still working in Netherland. From your friend Irvan, Oslo Norway.
Florin Comsa •
We bought a /16 IPv4 address space from ARIN many years ago and we curently are using subnets from this /16 in EMEA. We need to be able to use out of region IP space with ASN assigned by RIPE for new sites in EMEA region. Local ISP's will not advertise our IP space without route objects. Your recommendation of creating the route object in ARIN or maybe RADB will work for EMEA region with ASN assigned by RIPE? If we create IRR in ARIN or RADB can we use ASN assigned by RIPE with out of region IP space for new EMEA sites?
Nathalie Trenaman •
Hi Florin, Indeed, we recommend to register the route objects for your /16 in the ARIN IRR. You will be able to create them with the ASNs assigned by RIPE. Alternatively, you could consider transferring the /16 from ARIN to RIPE NCC, if you are already a member here.