Security and Trust in the Internet Routing Registries operated by the RIRs

Please note that I am writing this as an individual as I am not employed by the RIPE NCC anymore.

Abstract

This article is addressing a number of items discussed at RIPE 69 and on the RIPE Database working group mailing list since then. I will cover the following topics in this article:

1. Use of RIPE-NCC-RPSL-MNT in "mnt-by:" attributes
2. What issue(s) need to be solved
3. Quick (temporary) solution to the problems of a public password
4. source: RIPE
5. Flattening of MNTNER namespace across some RIR databases
6. Long term solution of cross registry authorisation across some RIR databases
7. Migration of AFRINIC ROUTE objects
8. Guidelines on operating the routing registry

1. Use of RIPE-NCC-RPSL-MNT in "mnt-by:" attributes

Currently anyone can use the maintainer object (MNTNER) RIPE-NCC-RPSL-MNT to maintain any of their data. It has a public password so it is easy and convenient to use. But using it in this way takes us back to the days of RIPE-NCC-NONE-MNT. A MNTNER with no "auth:" which was deprecated about 12 years ago.

The first step to fix this issue is trivial. The database software maintains internal lists of 'protected' MNTNERs. These lists limit the way certain MNTNERs can be used by users. One solution could be to add RIPE-NCC-RPSL-MNT to one of these lists and it can no longer be used in a "mnt-by:" attribute. That way it won't be possible for any user to reference this MNTNER, so it can no longer be used as (very weak) protection.

The second step is more difficult:  a cleanup. Notifications can be sent initially to any contacts listed in these objects. Then after a while any remaining objects maintained by this MNTNER could be locked. But then the problems start. Depending on the object types, there may be no clue who has authoritative control over these objects. Use of this MNTNER can make objects totally anonymous. A count by object type of how many objects have this MNTNER as a "mnt-by:" was sent to the RIPE DB WG mailing list some time ago . It is possible to identify the authoritative user of resource objects. For MNTNER, PERSON and set objects it may not be easy or even possible.

Just to clear up a possible misunderstanding, the use of this MNTNER in the "mnt-by:" attribute of any object is a completely separate issue to routing authorisation. Abuses of the "mnt-by:" attribute are easy to find in the database as it is shown in the object. However, currently there is nothing in an object whose creation was authorised by this public password to show that this was how it was created. One would have to work it out by understanding how these objects were created, for instance by looking at parent or related objects or checking resource keys against the delegated stats files of the Regional Internet Registries (RIRs).

2. What issue(s) need to be solved

The main issue is having a MNTNER object in the RIPE Database with a public password. This MNTNER allows any user to bypass hierarchical authorisation when creating certain ROUTE objects or copies of AUT-NUM objects for which the RIPE NCC is not the authoritative RIR. (For details of how this is done see the RIPE Labs article Using the RIPE Database as an Internet Routing Registry ).

Just to be clear: users can NOT create copies of address space objects in the RIPE Database for non RIPE NCC authoritative address space, i.e. INET(6)NUM objects. This is all locked down by use of the "mnt-lower:" attributes in the database.

What can be duplicated however by anyone at the moment using this public password is any AUT-NUM object for non RIPE NCC administered ASNs and ROUTE objects related to address space and ASNs that are both non RIPE NCC administered. The authoritative registrants of these resources may not be aware of the creation of these objects in the RIPE Database.

The middle ground is where one of these resources (address space or ASN) is a RIPE NCC administered resource and the other one is not. Authorisation from the other one can be bypassed when creating a ROUTE object without their knowledge. But this has to be done with the full knowledge of and authorisation from the RIPE NCC member who holds the RIPE NCC administered resource. It is not possible to bypass the authorisation of any RIPE NCC administered resource when creating objects in the RIPE Database. So objects within this middle ground can only be created by RIPE NCC members.

The main problem seems to be when these objects are created by mistake or maliciously, without the knowledge of authoritative resource holders in other regions and would not be approved if they knew about it. Also the authoritative resource holders cannot easily remove these objects from the RIPE Database should they wish to do so.

There is talk about how to filter out these objects where authorisation has been bypassed as some users don't trust them. If users had more trust in these objects, there might be no need to filter them out of queries.

3. Quick (temporary?) solution to the problems of a public password

This issue was raised just before the RIPE 69 meeting when questions were asked about the use of this public password. However, this is not a new issue. The community agreed to introduce this MNTNER when the RPSL database was first deployed exactly 14 years ago. It was an 'open secret' that the community lived with because of the technical and administrative benefits it provided to the routing community (see below).

The simplest way to resolve the consequences of this public password is to use the existing notification mechanism. Anytime an object is created in the RIPE Database using this public password to bypass authorisation, lookup the resource(s) in the authorised RIRs database, find the contacts and notify them that this object has just been created.

Most of the software to do this already exists. It is just a small extension to the notification mechanism. It also applies equally well to all the other four RIR’s resources. It does not require them to be using the same software as the RIPE Database. This could be deployed very quickly and could be notifying resource holders of potentially rogue object creations while a full solution of cross registry authorisation is still being worked out.

If this works well and there is confidence that the right people are being notified, a second step could be to either provide a link in the notification to allow the authoritative resource holder to delete the rogue object from the RIPE Database, or hold back the object creation in the RIPE Database pending approval by the authoritative resource holder. This pending mechanism is already built into the RIPE Database software for RIPE only resources.

This would also satisfy the requirements  stated on the mailing list some time ago in a quick and simple way:

• Permit documentation of legitimate use of out-of-region resources
• Stop people from adding "route:" objects for which they are not authorised

If notifications were sent out for all existing objects in the RIPE Database that have bypassed authorisation and these objects are deleted if the resource holder requests it, or no response is received to the notification, we could phase out those objects that are currently not trusted.

4. source: RIPE

I have seen some discussion in recent months about using the "source:" attribute in the RIPE Database to 'identify' resource objects whose creation was authorised using the public password. In the discussion there was an assumption that automated queries will not query with "-s RIPE". From my recollection of looking at query logs over many years there are lots of automated queries still using the '-s' query flag. This is a throw back to the days when you could do referral queries through the RIPE Database. Although the referral mechanism (see footnote [1] ) has long since been deprecated, many of the scripts making these queries have not been changed. The  '-s' query flag is still supported, so for "source: RIPE" these queries continue to work. The proposed change to the source value, and the automated filtering that would need to be added to the query output when '-s ripe' was included in a query, would change the behaviour of these historical queries that still use '-s RIPE' now. Users who still use this flag may not be aware of the change.

5. Flattening of MNTNER namespace across some RIR databases

I saw a brief comment on one of the RIPE mailing lists some time ago about flattening the MNTNER namespace being a pre-requisite for cross registry authorisation. I don't understand why this would be a pre-requisite of any cross-registry authorisation or why it would be considered a good thing to do. I do see quite a number of issues in attempting to do this.

The idea seems to be to have a single namespace for MNTNER objects across those RIRs that use the RIPE Database software (RIPE NCC, APNIC, AFRINIC), making the MNTNER names unique. But all objects across all 5 RIR databases already have globally unique names: A combination of object primary key, object type and source uniquely identifies any object in any of the databases. So 'aardvark-mnt,mntner,ripe' is a unique reference to my MNTNER object in an RIR database.

Trying to flattening the namespace could potentially be controversial, technically difficult to maintain and administratively complex, depending on how many overlapping names already exist. I will just list a few of the issues that would have to be considered to do this:

• If there is an overlapping name between two databases, who has to change?
• Who decides who has to change?
• What if neither party wants to change?
• What if either or both MNTNER objects have unresponsive contact details? (think 2007-01 )
• Organisations operating in multiple regions may create MNTNER objects with the same name for ease of administration
• If this flattening was ever achieved, how would potential race conditions be handled when creating a MNTNER object in two databases at the same time with the same name?

With the possible introduction of personalised authorisation (i.e. adding "auth:" to PERSON objects), would this then have to be extended to flattening the Nic Handle name space across the same RIR databases? I suspect that would be an impossible task.

6. Long term solution of cross registry authorisation across some RIR databases

I believe, cross registry authorisation is the ultimate solution if you want strong authorisation on out of region ROUTE object creation. It was looked into about 10 years ago but never pursued. It is technically difficult and may only be possible for those RIRs using the same software for the registry. One question to be considered before embarking on such a solution, does the effort give a result that is so much better than using notifications and holding back the object creation pending confirmation (as described in section 3 above and which covers all the RIRs)?

7. Migration of AFRINIC ROUTE objects

Many comments have been made on the mailing lists about the potential reduction of the number of ROUTE objects in the RIPE Database related to non RIPE NCC administered resources after AFRINIC data has been migrated to the AFRINIC Database. From this email we see that there are 37,683 ROUTE objects in the RIPE Database related to AFRINIC address space.  AFRINIC recently set up an IRR in the AFRINIC Database and encouraged operators in the AFRINIC region to move their objects to the AFRINIC Database. At the time of writing this article, I only found 368 ROUTE and 12 ROUTE6 objects in the AFRINIC Database. So I don't think we can count on any significant reduction of  ROUTE objects in the RIPE Database related to AFRINIC address space in the RIPE Database any time soon.

Guidelines on operating the routing registry

I would like to expand a little on a point made to the Routing WG recently . It was quite rightly pointed out that at the moment there is no policy governing the RIPE IRR. However, this doesn't mean that the RIPE NCC invented this IRR system all on its own. In fact, the current RPSL version of the RIPE Database, including the IRR, was designed, developed and deployed 14 years ago. This was done with extensive consultation with the community through RIPE working groups and in collaboration with other organisations like the IETF . The system that was deployed was agreed to by the community at that time and followed the IETF standards defined in a number of RFCs . Many changes have been made to the system since, all after consultation with the community and approval by the appropriate RIPE and IETF working groups.

However, there is no single document that one can point to that defines how the IRR operates or what are the responsibilities of any parties involved in the operation and use of the IRR. So when a discussion occurs on a mailing list about a rogue ROUTE or AUT-NUM object in the RIPE Database, the RIPE NCC has no authority to do anything. If it could be defined and written down somewhere what actions the RIPE NCC should take in certain cases, then discussions on the mailing list might lead to a successful conclusion if there is consensus.
 

Footnote [1]: There was a historical use case for adding '-s ripe' to a query to assert that you only wanted objects returned from the RIPE Database. This is no longer necessary. By default you only get objects from the RIPE DB. If you want objects from RIPE and APNIC DBs, for example, then you would now add '-s ripe,apnic-grs'.