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

Hi Ronald

I have added some more comments below about this specific ROUTE object 
you gave as an example.

On 21/11/2016 01:12, Rene Wilhelm wrote:
> 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

If you query this prefix using webupdates and select ' Search resource 
objects in all available databases' you will see the address range is 
from APNIC region

     inetnum:         36.96.0.0 - 36.127.255.255
     netname:         CHINANET-ZJ
     descr:           CHINANET Zhejiang province network
     descr:           Data Communication Division
     descr:           China Telecom
     country:         CN
     admin-c:         DUMY-RIPE
     tech-c:          DUMY-RIPE
     notify:          antispam at dcb.hz.zj.cn
     mnt-by:          APNIC-HM
     mnt-lower:       MAINT-CHINANET-ZJ
     mnt-routes:      MAINT-CHINANET-ZJ
     mnt-irt:         IRT-CHINANET-ZJ
     remarks: --------------------------------------------------------
     remarks:         To report network abuse, please contact mnt-irt
     remarks:         For troubleshooting, please contact tech-c and admin-c
     remarks:         Report invalid contact via 
www.apnic.net/invalidcontact
     remarks: --------------------------------------------------------
     status:          ALLOCATED PORTABLE
     source:          APNIC-GRS
     remarks:         ****************************
     remarks:         * THIS OBJECT IS MODIFIED
     remarks:         * Please note that all data that is generally 
regarded as personal
     remarks:         * data has been removed from this object.
     remarks:         * To view the original object, please query the 
APNIC Database at:
     remarks:         * http://www.apnic.net/
     remarks:         ****************************

Doing the same for the ASN you see it is from LACNIC region:

     aut-num:         AS52523
     descr:           COMPANHIA PAULISTA DE FORCA E LUZ
     created:         20130521
     source:          LACNIC-GRS
     remarks:         ****************************
     remarks:         * THIS OBJECT IS MODIFIED
     remarks:         * Please note that all data that is generally 
regarded as personal
     remarks:         * data has been removed from this object.
     remarks:         * To view the original object, please query the 
LACNIC Database at:
     remarks:         * http://www.lacnic.net/
     remarks:         ****************************


This is what we refer to as an 'out of region' ROUTE object. This is one 
of the more extreme cases where both the prefix and ASN are outside the 
RIPE region. But the RIPE Database allows creation of such objects. 
Currently there is no authorisation done by the real resource holders 
and no notifications are sent to them that this object has been created 
in the RIPE Database. The resource holders in APNIC and LACNIC regions 
may not know this ROUTE object exists. Anyone can create such an object.

This issue has been discussed at several recent RIPE Meetings but no 
consensus has been reached on how to move forward. But as you point out, 
there is an added complication now with some of these objects being 
locked. This was not part of the previous discussion on the subject. So 
no one is maintaining these objects, no one can delete them and maybe no 
one wants it to be there. And as you point out below, some people may 
give this (rogue) object credibility because it exists. Whoever created 
this object is unlikely to ask the RIPE NCC to unlock it as they may not 
have any valid reason for it being there. So this object is stuck in 
limbo... Perhaps if one of the resource holders asks the RIPE NCC to 
delete it they will do, but someone has to tell the resource holders it 
exists.

cheers
denis

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20161121/788504e4/attachment.html>