[db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database

HI All

Sorry Trudy but what you have done is not the answer to the problem you
have posed. Through your total lack of understanding of how the database 
works, all you have done is create more problems. In fact I am surprised 
YOU actually made an announcement about the database given how little 
you understand it, despite starting as customer support for the database.

OK lets look at the problem and its real causes. You state that 'people' 
can hijack address space by finding these unmaintained PERSON or ROLE 
objects, modifying them and posing as the 'owners' of the address space. 
'owner' being a consequence of the gold mine created over something that 
no one ever owned before and should still not own.

So how do they claim to be the owner? They change the details in the 
PERSON object, including the PERSON name, and maybe add their own MNTNER 
to it. But the key element here is the name. In the past you could not 
change the PERSON object name. This is a change that was implemented a 
couple of years ago and has led to this current issue. ONLY by changing 
the name of the PERSON object can you claim to be the 'owner' of this 
address space. If you can't change the name and you can't produce any ID 
to show you are the named person, then you have no claim over the 
address space. Hijacking in this way is not possible. So if you had 
rolled back that change to allow changes to the PERSON object name you 
would have fixed this problem.

What you have now done is create a massive panic. You have locked almost 
a million objects with no possibility of substantiating the owners of 
those objects. You have created a huge redundancy of stale data in the 
database. Everything still works as it did with these objects locked. 
But we know from experience no one will now bother to 'fix' any of these 
objects. No one will be able to update them and few people will bother 
to replace them. So this will just remain as stale data for many years. 
And there is nothing the RIPE NCC can do about any of this referenced, 
stale data now. It will just sit there and you have no idea if it is 
still valid or not.

Even if anyone does replace the locked object, unless you have 
re-enabled the automatic cleanup of unreferenced objects, which has been 
disabled for many years, the replaced objects will just persist 
indefinitely. The automatic cleanup used to delete unreferenced objects 
after 90 days. That is the time period that was agreed by the community. 
The fact that you are now talking about 180 days shows that the past 
community decisions have been lost in the mists of time.

The points about data protection are not valid. Anyone can reference any 
PERSON or ROLE object in any object to give the impression of a 
connection. Anyone can create a copy of your PERSON object with all the 
same details including the name and make references to this object as if 
it was you and you have no control over this and not even any knowledge 
that it has been done.

I will say this just to make it a matter of public record, even though I 
know no one will acknowledge the point or even make any reference to 
this point, but these problems are a consequence of an outdated data 
model that absolutely no one believes needs even to be reviewed. I have 
worked with this database for 15 years looking at it from every angle 
and I know it is not possible to fix the data protection issues with 
this data model, even though no one believes me or will even engage with 
me to discuss it openly.

So much for an alleged 'open, transparent, bottom up process'.... In 
reality it is a top down, cartel driven, self interest (gold mine) 
decision making body that few new members feel able to contest on these 
antiquated mailing lists that are totally unrepresentative of the wider 
database user community. I know 'people' will hate me for saying this 
and I hate the thought of Donald J Trump becoming the US president, but 
I agree with one thing he says....sometimes you need to say things that 
are not pc and go against the establishment because this is how it 
really is...

cheers
denis

On 07/04/2016 10:23, Trudy Prins wrote:
>
> Dear colleagues,
>
> The RIPE NCC Executive Board (EB) endorsed a proposal on how to deal
> with a vulnerability for RIPE Database users. Following their advice,
> the RIPE NCC proactively locked 848,986 unmaintained PERSON objects
> and 1,206 unmaintained ROLE objects on 6 April 2016.
>
> Since reaching the last /8, IPv4 address space has become more
> susceptible to hijacking. Unmaintained PERSON and ROLE objects are
> highly at risk of being found and hijacked. In addition, unmaintained
> PERSON and ROLE objects are an issue with regards to data protection
> obligations.
>
> The potential impact of abuse led us to consult with the EB on this
> intermediary solution before engaging with the community on the next
> steps. Exposing this issue without taking adequate measures would
> have left the RIPE NCC liable to third party damages.
>
> The proposed solution we outline below is a starting point, to be
> discussed by the community.
>
>
> Background: ===========
>
> Since 2010 it has been mandatory to protect PERSON and ROLE objects
> in the RIPE Database using a maintainer on "mnt-by:". A large number
> of PERSON and ROLE objects dating from before 2010 are still not
> protected in this way.
>
> Objects can be created that reference these unmaintained objects, but
> doing so will generate a warning.
>
> In recent years, given the scarcity of IPv4 address space, there is a
> higher risk of people searching for unmaintained PERSON or ROLE
> objects in order to pose as a resource holder to sell IPv4 space. In
> the case of legacy space, this could take place outside the view of
> the RIPE NCC if the address space is not registered with the RIPE
> NCC.
>
>
> Proposal: =========
>
> 1) All unmaintained ROLE and PERSON objects are now locked. As the
> RIPE NCC will not be able to correctly check all claims on
> unmaintained database objects, unlocking is not available. Offering
> to unlock these objects could leave the RIPE NCC liable to third
> party damages if due diligence is not followed.
>
> 2) Furthermore, the RIPE NCC modifies the existing warning about
> referencing unmaintained persons/roles to a similar warning about
> referencing locked persons/roles.
>
> 3a) The locked objects can remain as they are. In time, all locked
> PERSON or ROLE objects no longer referenced by other objects could be
> automatically deleted: the current thinking is a 180-day deletion
> timeout for these locked, unreferenced objects.
>
> 3b) If there is an operational need, new PERSON or ROLE objects
> should be created by the object owners. This solution puts control
> back into the hands of the object owners. The user can follow the
> existing process for creating and referencing new objects. If there
> is a use case for supporting bulk migrations where a reference to a
> locked PERSON or ROLE object should be replaced, the RIPE NCC can
> create a wizard in the RIPE Database webupdates section of
> www.ripe.net <http://www.ripe.net/>.
>
> We look forward to your feedback.
>
> Kind regards,
>
>
> Trudy Prins Manager Software Engineering RIPE NCC
>
>
>