report on nic handle reuse in the RIPE DB

Dear all,

for your reading pleasure :-)

This issue came up during the last RIPE meeting.

Best regards,
Joao Damas
RIPE DB Group Manager
RIPE NCC
-------------- next part --------------
NIC handle reuse in the RIPE Database
-------------------------------------

Current situation
-----------------
Currently when a database update requests the creation of a new NIC handle
for a newly created person or role object, by specifying the AUTO-X
(0<=X<=9), the software looks for an unused number in the sequence
of nic handles with the same initials.

The assignement is not sequential but rather tends to fill in the nic handle
space in a pattern with a random component, giving more chances to nic
handles with low numbers.

Thus, the new NIC handle doesn't necessarily have the biggest sequence
number used in the Database so far as it may use one corresponding to a
previous existing person or role object that was deleted some time after
and is now a "hole" in the sequence.

This can lead to misunderstandings and/or inconsistent data due to nic handle
replacement (either accidental or intentional).

A user may also specify a specific number for the nic handle when
sending in a request for creation of a person or role object. If the
requested nic handle is not currently in use the database the request for
that nic handle will be granted, otherwise an error will be generated.

This allows users to undo accidental deletions of person/role objects.

Consequences
------------
This has, in the past, lead to some problems where person objects were
replaced by unrelated person/role objects therefore making the contact
information invalid for some database objects.

Recently, the database software has been modified to perform some checks
on user actions when the user tries to delete contact information:

 Person and role objects can only be deleted when they are not being
 referenced by any other object in the database.

This helps to prevent accidental deletions while the object is still
needed in the databse.

This can't prevent the kind of "mailicious" deletions where all the referencing
objects are deleted and then the person object is also deleted. This can
only be
prevented through a different set of functionality in the Database: the
use of proper authentication.

Addressing the problem
----------------------
In the past discussions have taken place about proposals to prevent the
RIPE DB to reuse low numbered nic handles when generating new ones through
the AUTO mechanism, while still allowing users to request specific unused
low numbers.

Modifying the software to assign new handles that have sequence numbers
greater than the "last one used" could be straightforward except for one
detail,
the definition of the "last one used".

>From the non-sequential nature of the current algorithm it is clear that
there are a lot of holes (of variable size) in the nic handle space.

Also, some users attach special meaning to numbers such as 666, 1000, 2000,
5000, 10000 etc leading to a situation where a particular nic handle
sequence can have a more or less compact set with low numbers and then some
scattered arbitrarily large ones.

Simply picking the biggest number for a particular letter combination at a
particular moment will sometimes result in all new nic handles having
big numbers.

Also, the software would not be able to ensure that an arbitrarily big
nic handle was not used and deleted in the past.

In short, to ensure that no nic handle gets reused the RIPE DB would have
to forbid also specific nic handle assignement or alternately keep track of
all nic handles ever assigned.

We believe this is not a desired outcome.

Two letter combinations are about 700. Three letter combinations are about
17600 and 4 letter combinations are about 457000. The nic handle space is
repeated for every possible registry (RIPE, APNIC, ARIN,...)

The new DB currently being developed could be engineered to keep a marker
for every nic handle that is ever used. However, this can lead to a rather
big table since essentially no deletions would occur in the table of nic
handles (there are currently over one million entries).

Conclusion
----------

We believe there is no perfect solution and that the one taken will
depend on the community's perspective on how important this problem is.

We suggest to keep the current behaviour.


We request the community to evaluate the importance of modifying the
current DB behaviour in this regard.