# RIPE Database Security

A collection of documents designed to help with security of whois data stored in the RIPE Database

# Maintainers

Every object in the RIPE Database must be protected, to ensure that only authorised people can make changes. To facilitate this, there is a dedicated object which is used to protect all other objects you manage: the maintainer. This page explains how to set up a maintainer for yourself and your organisation, as well as handling delegation of authorisation to other parties.

The maintainer (mntner) object is used to protect other objects in the RIPE Database. This is done by referring to the maintainer from the object you want to protect, using the "mnt-by:" attribute. The maintainer contains one or more authentication methods that you can use to authorise making changes to your objects.

Maintainers are anonymous. Other than the authentication references they contain, there is nothing that ties them to a specific person, group or organisation. Authentication is handled as a "logical OR", meaning that if you know one of several credentials associated with a maintainer, you can make changes to the objects that refer to it. In the example above, two people can use their RIPE NCC Access (single sing-on) account to make changes to the inet6num object, or the PGP key can be used. Which authentication method is best for your use case is explained in a separate section: Protecting your data in the RIPE Database.

Most commonly, a maintainer object is maintained by itself, meaning that the "mnt-by:" attribute of the maintainer refers to the same object. If you want to edit details, for example add or remove an authentication, you simply need to use one of the existing authentication methods. In the example above, one of the three authentications can be used to add a forth, such as new colleague joining the team.

What makes the maintainer system flexible is the fact that you have a lot of freedom in: * The number of maintainer objects you create * The number of maintainers you refer to from each RIPE Database object * The kind and number of authentication methods you use in each maintainer * Delegation of authorisation to a specific person or group * Controlling what kind of objects a certain group can create (such as route(6), domain and inet(6)num objects)

Given this flexibility, you must ensure you make the right choices when setting up authorisation. There are some important concepts and best practices to keep in mind which are explained in each of the following sections.

# The Default Maintainer

If you are an LIR and you have received Internet Number Resources, several objects are created by the RIPE NCC in the RIPE Database to reflect this. These objects are managed by the RIPE NCC, but you have control over some of the attributes, such as setting the administrative and technical contact person. In order to allow you to make these changes, an additional maintainer will be present on the object, the so called "default" maintainer. You have to select this maintainer on the Account Details (opens new window) page and this will be reflected on all existing and new objects that have joint responsibility: allocations for IP resources and the organisation object.

After selecting the default maintainer, you can change all of the attributes you could previously modify by using the Object Editors - such as technical, administrative and abuse contact details - Through the RIPE Database itself. You can use any update method you like, e.g. webupdates, syncupdates or email updates.

# Personal Maintainers Versus Shared Maintainers

When you first use the RIPE Database, you need to create some basic objects. Every object you create in the database must be maintained. That means you need a mntner object. This object must reference a role (or person) object as a contact. However, the role (or person) object must be maintained. Therefore, a user cannot create either of these two objects first using any of the usual update methods. This means when you start using the RIPE Database, you first step would be to create a role and maintainer pair (opens new window) for yourself.

Most other objects, especially the ones that are related to your resources, should be editable by you and your colleagues in the IT department or Network Operations Centre. For these objects you should be using a single maintainer that is shared by a group of people. In most cases, this maintainer was created when you registered as a RIPE NCC member or became a resource holder in another way. If not, it is always possible to create a shared maintainer (opens new window) at a later point.

Keep in mind that sharing a maintainer doesn't mean sharing the credentials as well, such as a password or a key. As explained earlier, a maintainer can contain multiple authentication attributes, so each person that has access to it can use their own set of credentials.

# Delegating Authorisation Using Maintainers

The idea behind delegation of authorisation is that you can authorise a certain group (either within or outside your organisation) to create objects under a certain parent object that you control. For example, your can allow your colleagues who are responsible for the BGP routing configuration to create route(6) objects to register the announcement in the Internet Routing Registry (IRR), and nothing else. Likewise, you can authorise your DNS group to request Reverse Delegation by creating a domain object and nothing else.

For this purpose, three attributes exist:

* "mnt-lower:", for hierarchical control over one level more specific objects
* "mnt-routes:", for the creation of **route(6)** objects in the IRR
* "mnt-domains:", for requesting Reverse Delegation of DNS by creating a **domain** object

The "mnt-lower:" attribute specifies an existing mntner object used for hierarchical authorisation. It controls creation of objects one level more specific in the hierarchy of an object type (this only applies to inetnum, inet6num, as-block, aut-num, route, route6, or domain objects).

The most common occurrence of the "mnt-lower:" attribute is in the IP address allocation(s) that you have received from the RIPE NCC. For example, if you are an LIR and you have an IPv6 allocation, it is represented in the RIPE Database as an inet6num object. Because the allocation is managed by the RIPE NCC, one of the "mnt-by:" attributes is set to RIPE-NCC-HM-MNT and the other is set by you after choosing the default maintainer. These are some of the attributes you would see:

inet6num:   2001:db8::/32
org:        LIR-ORG-RIPE
status:     ALLOCATED
mnt-by:     RIPE-NCC-HM-MNT
mnt-by:     LIR-NOC-MNT

The RIPE-NCC-HM-MNT maintainer prevents you from making changes to some of the attributes that are part of the RIPE NCC's registry management, such as the "netname:". Your LIR's default maintainer allows you to make changes to attributes you manage, such as the "admin-c:" and "tech-c:". In addition, it allows you to create assignments, as well as route(6) and domain objects under this parent block. However, if you wish to delegate the creation of child resource objects to a separate group, you can do so by creating an additional maintainer for them and specify it as "mnt-lower:":

inet6num:   2001:db8::/32
org:        LIR-ORG-RIPE
status:     ALLOCATED
mnt-by:     RIPE-NCC-HM-MNT
mnt-by:     LIR-NOC-MNT
mnt-lower:  LIR-IPMGMT-MNT

Likewise, you can delegate control over the creation of **route(6)**and domain objects by adding a "mnt-routes:" and "mnt-domains:" attribute to the allocation. Keep in mind that you first have to select a default maintainer before you can do this. The resulting allocation object would look something like this:

inet6num:    2001:db8::/32
org:         LIR-ORG-RIPE
status:      ALLOCATED
mnt-by:      RIPE-NCC-HM-MNT
mnt-by:      LIR-NOC-MNT
mnt-lower:   LIR-IPMGMT-MNT
mnt-routes:  LIR-RTRMGMT-MNT
mnt-domains: LIR-DNSMGMT-MNT

After you have done this, you can achieve fine-grained control over the creation of inet(6)num, route(6) and domain objects.

In this example, route and domain objects are managed by separate maintainers: LIR-RTRMGMT-MNT and LIR-DNSMGMT-MNT respectively, as specified in the allocation. IN addition, a "nt-lower:" was specified in the aggregate prefix for the broadband pool (2001:db8::/36). This allows for the creation of more specific objects below it by LIR-BROADBAND-MNT:

In general, keep in mind that when as inet(6)num, route(6) or a domain object is created, authentication is required from the parent object. If the parent has a "mnt-lower:", "mnt-routes:" or "mnt-domains:" attribute, this is the mntner that will need to be authenticated against. Otherwise the parent "mnt-by:" attribute is used.