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

Hi,

On 11/20/16 10:05 PM, Ronald F. Guilmette wrote:
> [...]
> 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.

To query version history for route objects you need to include the
origin AS number in the query. Together with the prefix that identifies
a single route object in the database:

whois -h whois.ripe.net ' --list-versions 36.116.128.0/17AS52523'
[...]

rev#  Date              Op.

1     2016-03-12 20:11  ADD/UPD
2     2016-04-25 15:15  ADD/UPD


whois --show-version 1 36.116.128.0/17AS52523

% Version 1 of object "36.116.128.0/17AS52523"
% This version was a UPDATE operation on 2016-03-12 20:11
% You can use "--list-versions" to get a list of versions for an object.

route:          36.116.128.0/17
descr:          EU route
origin:         AS52523
mnt-by:         RIPE-NCC-RPSL-MNT
created:        2016-03-12T19:11:19Z
last-modified:  2016-03-12T19:11:19Z
source:         RIPE


So this is one of those cases which Denis described: the insecure maintainer
RIPE-NCC-RPSL-MNT was replaced by RIPE-NCC-LOCKED-MNT on 2016-04-25.

> (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.

some quick scripting suggests the bulk of the (ipv4) route objects which
have mnt-by RIPE-NCC-LOCKED-MNT today only ever had mnt-by RIPE-NCC-RPSL-MNT
before.

12 route objects have been locked more than a decade ago, due to
deprecation of the NONE authentication scheme. For example:

route:          62.135.0.0/18
descr:          LINKdotNET Route
origin:         AS24863
mnt-by:         RIPE-NCC-LOCKED-MNT
remarks:        Maintainer RIPE-NCC-NONE-MNT removed and object
remarks:        LOCKED by the RIPE NCC due to
remarks:        deprecation of the NONE authentication scheme.
remarks:        Please visit the following URL to unlock this object
remarks: http://www.ripe.net/db/none-deprecation-042004.html
created:        2002-07-30T17:02:26Z
last-modified:  2004-04-30T06:14:23Z
source:         RIPE

-- Rene
>
> 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?
>
>