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?