RIPE Database

Proposal to change the behaviour of "mnt-lower:" attribute in inetnum, inet6num and domain objects

Summary:

The purpose of this proposal is to improve the security of the RIPE Whois Database. Currently all route objects use Routing Policy System Security (RPSS) for authorisation from a parent object ("mnt-routes:" attribute).
As agreed by the RIPE Community, this proposal changes ALL hierarchical object types so that they default to requiring authorisation for more-specific object creation.

More details:

In RPSS, objects use "mnt-lower:" to specify a maintainer which has the ability to authorise the creation of more-specific objects. If a "mnt-lower:" attribute is not present, then the "mnt-by:" of the less-specific object is used.

In March 2003 the proposal was circulated to implement the same scheme for the creation of inetnum, inet6num and domain objects:

http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00033.html

Some inetnum objects will be affected by this change, allocation objects in particular, as they are maintained by the RIPE NCC. If an allocation object has no "mnt-lower:" attribute, the new scheme will use "mnt-by:" to authorise the creation. After this change has been made, the LIR must have a "mnt-lower:" to create any new assignments for their allocations.

To solve this problem, all allocation objects without a "mnt-lower:" attribute should be modified to include this attribute pointing to the LIR's maintainer. As there is no exact mapping between an LIR and the maintainer used by this LIR, a search was performed to find a suitable maintainer for every allocation affected by this change.

The algorithm was (in order of decreasing priorities):

1. Use the maintainer from "mnt-by:" of all assignments from this allocation
2. Use the maintainer from "mnt-routes:" of this allocation
3. Use the maintainer from "mnt-lower:" of all other allocations of this LIR
4. Use the maintainer from "mnt-routes:" of all other allocations of this LIR
5. Use the maintainer whose name is relevant to the LIR's name
6. Use the maintainer whose description refers to the LIR's name
7. If a maintainer is not found, a new maintainer will be generated. The allocation object will be updated with this maintainer in "mnt-lower:" and its password will be available through the LIR Portal.

This algorithm reflects how the maintainer objects are used in the RIPE Whois Database.

The plan is as follows:

1. Prepare a list of affected allocations and their possible maintainers
2. Send out notifications to allocation contacts
3. Wait for feedback, gather new data
4. Update allocation objects

Following approval by the RIPE Community, this proposal will be applied to the RIPE Database.

For more details about the background and heuristics for this proposal, please see the RIPE 46 Meeting presentation "mnt-lower:" issues with inetnum at:

http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-db-allocations-and-mnt-lower/

Current status:

The latest proposal sent to the community is available at:

http://www.ripe.net/ripe/mail-archives/ncc-services-wg/2003/msg00303.html

Preliminary checks were completed and first notifications about the affected allocation objects were sent on October 7, 2003.

Allocations which did not have a "mnt-lower:" attribute pointing to the LIR's maintainer have been modified as of November 10, 2003.

The LIR Portal can be used to retrieve the password for a newly-generated maintainer object. The Allocation Editor within the LIR Portal can be used to modify the allocation objects "mnt-lower:" attribute.

The LIR Portal can be accessed at:

https://lirportal.ripe.net

You can update the generated maintainer object by usual procedure:

via Webupdates or e-mail to auto-dbm@ripe.net.