[db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database
- Previous message (by thread): [db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database
- Next message (by thread): [db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hank Nussbacher
hank at efes.iucc.ac.il
Thu Apr 7 21:31:14 CEST 2016
On 07/04/2016 11:23, Trudy Prins wrote: Can you detail what attempt was performed to try to contact the person or role object? Thanks, Hank > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/db-wg/attachments/20160407/e70f0bf8/attachment.html>
- Previous message (by thread): [db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database
- Next message (by thread): [db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]