[db-wg] Puzzled by RIPE-NCC-LOCKED-MNT

Thank you very much ripedenis at yahoo.co.uk for trying to anwer my question
about the objects maintained by RIPE-NCC-LOCKED-MNT.  I wish that I could
say that the manner in which that handle has been used, and is currently
used in the data base is now all 100% clear to me, but actually, I'm
still a bit befuddled.  I have another question or two, and a genuine
concern about the way this is being used.

In message <2050489988.801119.1479640620339 at mail.yahoo.com>, 
ripedenis at yahoo.co.uk wrote:

>This was another fix done by the RIPE NCC that was requested by the community.
>The MNTNER 'ripe-ncc-rpsl-mnt' has a public password listed in a "remarks:"
>in the object. So it is not secure. This object only exists to create
>ROUTE objects for out of region resources. Again it is not possible now for
>any user to create an object referencing this MNTNER. But many objects were
>created until recently with this MNTNER. So the RIPE NCC locked all such
>objects as another security fix.

I've done a reverse WHOIS query for all objects that are mnt-by:
RIPE-NCC-LOCKED-MNT.  I then programatically plucked out just the 
relevant route objects and ran some summary analysis on those.

In the data base at the present time, there are on the order of 2,120
route objects having RIPE-NCC-LOCKED-MNT as the mnt-by value.  Of these
2,120, the overwehlming majority, 2,107 of them, have a last-modified
date of 2016-04-25.  From this I conclude that there must have been
some sort of large "event" that took place on that date where vast gobs
of route objects had their mnt-by set to RIPE-NCC-LOCKED-MNT.  Based
on what you wrote, I gather that this was done, en mass, by RIPE NCC,
on that date, at the request of the community, in order to further
shore up the previously weak security on all the relevant objects.

Correct so far?

You also kindly included an example of what one specific route-set object
had looked like prior to the time that it has its mnt-by set to
RIPE-NCC-LOCKED-MNT.  I am guessing that you were able to obtain this
via judicious use of the --list-versions and --show-version options.
Is that correct?

I have just now been trying to apply those options to a single route
object and so far I am not having any success at all.  Are those options
supposed to work for individual route objects?  If so, then obviously
I'm just doing it wrong, and getting only errors back.  If you could
show me the correct syntax for using these options on individual route
objects, I'd be most greatful.  For example, if you could show me how
to view the different verssions of the 36.116.128.0/17 route object,
that would be great.  (It would be very helpful to be able to know who
or what was supposedly maintaining that object, and others of interest
to me, prior to the time when they were set to RIPE-NCC-LOCKED-MNT.

Anyway, here is my concern... I have just been having an email conversation
with one provider in the RIPE region.  I can summarize the conversation
as follows:

      ME:  You should not be allowing your peer/customer to announce
           route A.B.C.D/nn.

      HIM:  We filter by using the RIPE route registry.  There is a route
            object in the RIPE data base that says that our peer/customer
            can announce A.B.C.D/nn.

I am concerned that in some cases the RIPE data base contains some route
objects that should not have been allowed in there in the first place,
and that to make matters worse, some of these now have mnt-by set to
RIPE-NCC-LOCKED-MNT which has _two_ possible ill effects, i.e. (1) it
hides the identity of the party who put the route object into the data
base in the first place and (2) it in effect freezes in place some
improper route objects that should never have gotten into the data base
in the first place.  And in some cases, for some of the providers who
may be checking the routes that they either originate or pass against
the RIPE data base, this may have the effect of permanently legitimizing
bogus and perhaps even illicit routes.

I would like to know if anyone other than me thinks this might be an
issue.  I mean how will the bogus route objects ever be removed if they
are set to RIPE-NCC-LOCKED-MNT?