3.10.4 Who Maintains the Data?

This is one of those areas that some users don't pay much attention to, but it is one of the most important questions regarding the use of the RIPE Database. Anyone authorised to maintain your data can cause serious damage to your network, your business and the business of your customers if they make a mistake. Authorisation is an all or nothing concept. You cannot authorise someone to create and modify customer's details but not delete it, for example.

For details of the technical workings of authorisation see the section, 'Authorisation'. This section is about how to set up who can authorise what.

The authorisation model is based on the mntner object. This is a box that holds credentials. There are different types of credentials with passwords, PGP certificates and single sign-on (SSO) usernames being the main ones. At the time of writing, these credentials don't need to match anyone who is registered in the RIPE Database with a person object. They are simply lists of credentials that can belong to anyone. It is therefore not possible for the database software to identify ‘who' authorised an update. The introduction of SSO as a credential is a step in this direction.

Every object in the RIPE Database must now be protected by a mntner object referenced by a “mnt-by:” attribute. There are still some historic person and role objects without protection, but a “mnt-by:” attribute must be added if they are updated. The mntner object is also protected by a “mnt-by:” attribute. Normally, this references itself.

For a small organisation with only a few objects in the database you may decide that you only need one mntner object. This is created with one or more credentials and maintains itself. Every object you create in the RIPE Database is maintained by this mntner object. The people whose credentials are in the mntner object all have equal and full control over all of your database objects. They can create, modify and delete anything. Because of the anonymous way credentials are used in the mntner object, the software cannot identify which credential made the update, only that a specific mntner object was used.

For larger organisations with potentially hundreds of thousands of objects in the database you may want to distribute authority to maintain data. How you distribute it depends on your business model. One example could be for a multi-national organisation with customers in different countries to partition your address space allocations by country. You could have a separate team managing the network in each country, each with their own mntner object. The “mnt-lower:” attribute on the partitioned allocations restricts control to those teams.

Another possibility is to have separate teams handling address space, reverse delegations and routing. This can be set up using the appropriate “mnt-xxx:” attributes. For example “mnt-routes:”.

You may also want to control who can grant authority to manage your data. Normally a mntner object maintains itself. This means anyone who has a credential in that mntner object can also change the mntner object. So they can add another password so that another person can make changes. In a large organisation, you may want a security team to control the mntner objects. In this case you can create a mntner object for the security team. All other mntner objects are maintained by this security team mntner. Only the security team can then allow someone else authority to maintain some data by adding their credential to the appropriate mntner object.