Apologies if you receive this twice, but I am still having problems with the mailing list. The first attempt to send this message made it to the archive an hour ago but still hasn't been sent out to list members...so I will try again... cheersdenis ----- Forwarded Message ----- From: "ripedenis@yahoo.co.uk" <ripedenis@yahoo.co.uk> To: Ronald F. Guilmette <rfg@tristatelogic.com>; "db-wg@ripe.net" <db-wg@ripe.net> Sent: Sunday, 20 November 2016, 12:17 Subject: Re: [db-wg] Puzzled by RIPE-NCC-LOCKED-MNT Hi Ronald You have touched on several issues here. I will take them one at a time. The current model of the RIPE Database was deployed in 2001. Before that there was another version that did not require mandatory authorisation. So when the data was migrated to the current data model any objects that did not have any authorisation had this 'ripe-ncc-none-mnt' added as an "mnt-by:". This MNTNER object did not have any password or pgp. It had the "auth: none" value. This meant that no authorisation was needed but made the objects syntactically correct. As with any major change backwards compatibility was essential. So anyone could use the auth value 'none' in their own MNTNER objects. This allowed users who were not familiar with using authorisation in the RIPE Database to comply with the syntax but not add any real authorisation. As you may have realised there is lots of static data in the RIPE Database. This is data that is still correct and still in use but has not needed to be changed in any way for, possibly, decades. For the users who manage this data they generally don't follow RIPE Database events and don't spend any time 'actively' managing this data. Everything just works so if it ain't broken there is no need to fix it. In 2003 it was proposed that this 'false' concept of authorisation was deprecated. That happened in 2004. Despite the publicity, many users with this static data simply got on with life. So now, 12 years later, there are still objects in the database that are maintained by this 'ripe-ncc-locked-mnt' from this security fix in 2004. Now lets jump forward to more recent times. The MNTNER object 'ripe-ncc-locked-mnt' is used by the RIPE NCC in any situation where data needs to be locked. It was used recently to lock the remaining unmaintained PERSON and ROLE objects. Until about 3 or 4 years ago (when the software was re-written in java), authorisation was not validated on object creation. So anyone could create any object referencing any MNTNER object in the database, including 'ripe-ncc-locked-mnt'. Of course as soon as you created it you were locked out as you would not have the authorisation for that MNTNER you referenced. But if you didn't need to modify it the object would sit quite happily in the database and you could still reference it. With the re-write of the software that issue was closed. So now you do need to authorise object creations. Another change that was added is that no one outside the RIPE NCC can add or remove any of the RIPE NCC's MNTNER objects. This includes the 'ripe-ncc-locked-mnt' object. If you try this now you get these errors: Create FAILED: [person] AUTO-1   test guy person:         test guy address:        amsterdam phone:          +31 nic-hdl:        AUTO-1 mnt-by:         ripe-ncc-locked-mnt source:         RIPE ***Error:   Authorisation for [person] TG5494-RIPE failed             using "mnt-by:"             not authenticated by: RIPE-NCC-LOCKED-MNT ***Error:   You cannot add or remove a RIPE NCC maintainer I did a free text search to find some ROUTE object that had this MNTNER, 'ripe-ncc-locked-mnt'. I found this example: route-set: rs-AS327795 descr: Tanzania e-Government Agency tech-c: GM16-AFRINIC admin-c: GM16-AFRINIC mnt-by: RIPE-NCC-LOCKED-MNT mnt-lower: eGA-MNT created: 2015-04-01T14:16:38Z last-modified: 2016-04-25T13:09:57Z source: RIPE But if you look at the history of this object you will see the original object was this: route-set:      rs-AS327795 descr:          Tanzania e-Government Agency tech-c:         GM16-AFRINIC admin-c:        GM16-AFRINIC mnt-by:         RIPE-NCC-RPSL-MNT mnt-lower:      eGA-MNT created:        2015-04-01T14:16:38Z last-modified:  2015-04-01T14:16:38Z source:         RIPE 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 could have jumped straight to this example, but I thought the history behind all these changes may help with understanding why some situations exist/existed. cheersdenis From: Ronald F. Guilmette <rfg@tristatelogic.com> To: db-wg@ripe.net Sent: Sunday, 20 November 2016, 5:21 Subject: [db-wg] Puzzled by RIPE-NCC-LOCKED-MNT I am having a bit of trouble decyphering the explanation/description of RIPE-NCC-LOCKED-MNT given on the following page, and I hope someone will help me to understand. https://www.ripe.net/publications/news/announcements/deprecation-of-the-none... It appears from the above, that there was a transition/reorganization that took place back around 2004, and that RIPE-NCC-LOCKED-MNT was set as the maintainer on various objects that were present in the data base at that time (specifically objects which were not already adequately password protected) in order to protect some such objects from unauthorized modification. Is that description approximately accurate, I mean to a first approximation? (I understand that I'm probably glossing over a number of the fine points here, but I am doing so just because I doubt that any of those are even pertinent to my real question.) So anyway, my real question is this: If in fact RIPE-NCC-LOCKED-MNT was just something which was used as a sort-of "passing phase" stop-gap mechanism, i.e. as just a convenient expedient for securing things that would otherwise poorly secured, and if it was only applied in this way back in 2004, and for perhaps a year or two afterwards, then what would be the explanation for a *recently created* data base object (e.g. a route object) that has a created: date of, say, 2014, 2015, or 2016 and also a mnt-by value of RIPE-NCC-LOCKED-MNT? Regards, rfg

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?

In message <d4986f5c-1160-b35f-7b9a-cf5a15ba47bf@yahoo.co.uk>, denis <ripedenis@yahoo.co.uk> wrote:

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

For the record, I didn't deliberately select that one as being in any way exemplary of anything special... just a random route which is listed as being maintained by RIPE-NCC-LOCKED-MNT. (In fact, I think that that one just happened to be the very last one on my creation-date sorted list of RIPE-NCC-LOCKED-MNT maintained routes.)

This is what we refer to as an 'out of region' ROUTE object.

Yes. So it would appear.

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.

I understand what you've just told me, and I appreciate you telling me (because I did not know these facts until now), but I hope and trust that you will understand it if I say that the facts you have just related to me are rather deeply disappointing. Setting my disappointment aside for a moment, I hope that you can help me to further understand your assertion that "Anyone can create such an object." I am anyone. How would *I* go about creating such an object in the RIPE data base, exactly? Is there a web form someplace that one simply fills out and then presto!

This issue has been discussed at several recent RIPE Meetings but no consensus has been reached on how to move forward.

As in all such cases, my guess is that the absence of consensus probably has less to do with the technicalities of the various proposals than it has to do with the definition of the term "forward" in this context. (My own view is that parties allowed to put information in the data base... information that other people may then rely on... should at least be "known" and/or at least "identifiable", i.e. for some value of "known" or "identifiable". If that is not the case, then it is not clear what materially separates the RIPE data base from a dumping ground for random gibberish, a la 4chan.)

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

Thank you for confirming the essence of my concern. Obviously, I'm not happy that such an issue exists, but it is at least of some minor comfort to know that I am not entirely alone in seeing that there could be an annoying issue here, albeit one that, to my knowledge, is, most probably, quite limited in scope.

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.

Well, now that I think about it, the problem is actually not materially different from the case where a route is listed as being maintained by someone/something -other than- RIPE-NCC-LOCKED-MNT, but where the maintainer cannot not be located or contacted after a reasonable effort to do so (e.g. died, became a Tibetan Monk, got hooked on crack and no longer uses the Internet, etc.) The problem, of course, is less about the identity of the pro forma mnt-by person or entity than it is about the response, if any, by NCC staff to a report of a bogus route, in particular where sorting out truth from fiction is difficult, e.g. where the legitimate registrant of the relevant space has himself (or itself) long ago died and gone on to the personal or corporate hearafter. (And of course it doesn't help the investigation any when the registrant in question is/was in a whole different region.) In my country (USA), with respect to real estate, we have something called a "title search". It costs some modest amount of money to have it done, i.e. for a given specific piece of property. I don't know all the details, but I gather that they check some number of data sources, and when they have done that, if no red flags pop up, then the search is considered "done" and the property is transferred. I assume that a similar process is applied, e.g. in the case where a person or company has died, without a will, and -the government- then has to come in and take over the remaining abandoned property. Maybe I'm stating the obvious, but I think that "Internet governance", such as it is, is going to have to formalize this kind of a process at some point, and in fact, it is somewhat remarkable that this hasn't already occurred. There's already lots of dead wood in all of the RIR WHOIS data bases... stuff left over from about 30 years of births and deaths... and I don't think that just leaving it all to rot in place is in any sense a solution. It is all starting to become rather, um, aromatic. Regards, rfg

Hi Ronald On 21/11/2016 02:46, Ronald F. Guilmette wrote:

OK, so this all is starting to make a little bit more sense now, however I am still puzzled. If I've understood correctly, then RIPE-NCC-RPSL-MNT was depreciated starting in 2004. And there is

No. The MNTNER 'ripe-ncc-none-mnt' was deprecated in 2004 and any object referencing only that MNTNER was locked at that time. The MNTNER 'ripe-ncc-rpsl-mnt' is still in use now as a means of bypassing authorisation for out of region resources to allow these ROUTE objects to be created in the RIPE Database.

even a comment block in the WHOIS record for RIPE-NCC-RPSL-MNT telling people NOT to use that. And it appears that that comment, and indeed the entire record for RIPE-NCC-RPSL-MNT were last modified way back in 2006. So would I be correct if I said that people were told, very explicitly, not to use RIPE-NCC-RPSL-MNT anymore, starting from around the 2004-2006 time frame? And if everbody was told that, explicitly, for the last 10+ years, then why were people still using that handle as the mnt-by on their newly created route objects... and why were they even -allowed- to continue using that... right up until as recently as 2016-03-12?

The comment says "Do NOT use this maintainer as 'mnt-by'". It was never intended to be used in that way but many people did as a convenience. Early this year users were prevented from using this MNTNER in the "mnt-by:" attributes of other objects and any objects that still referenced it were locked. The comment also says descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. This still IS the intended use of this MNTNER object.

I mean I understand that often times, not everybody "gets the memo" telling them "Don't do that anymore. Do this new thing instead." So, people being people, if you allow them to keep on doing the old thing, some of them inevitably will. The real mystery is why RIPE NCC effectively depreciated the use of RIPE-NCC-RPSL-MNT more than ten years ago, but then continued to allow people to use it anyway, apparently until just earlier this year.

I understand the concept of a "grace period" and of a "transition period", but TEN YEARS?? Wasn't that a bit, um, excessive?

In short, I'm not sure I understand why -new- uses of RIPE-NCC-RPSL-MNT were not simply made impossible on the day in 2004 when it was finally resolved that RIPE-NCC-RPSL-MNT should indeed be retired, going forward.

But I guess that's all water under the bridge now. I'm just saying that it doesn't make a lot of sense to me. But then I wasn't there at the time, so maybe in some obscure way it seemed to make sense at the time... and for 10+ year therafter, apparently.

Anyway, my real concern, which you didn't address, is still this one:

...

...

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?

Am I correct that at the current point in time, nobody actually even knows for sure who actually put the former RIPE-NCC-RPSL-MNT and now RIPE-NCC-LOCKED-MNT route objects into the data base and that thus, nobody even knows for sure who to ask whether or not those are even still needed or whether any of them are of any onoing usefulness?

See my previous response.

I don't imagine that at this point in time anyone has the stomach for simply purging all of the RIPE-NCC-LOCKED-MNT routes out of the data base (because there would probably be blood in the streets if that happened)

Many of these objects are there for a valid reason. cheers denis

but I again, looking back with 20/20 hindsight, it would appear that the task could have been made a lot less onerous all around if direct use of either RIPE-NCC-RPSL-MNT and/or RIPE-NCC-LOCKED-MNT by anyone other than NCC staff had simply been disallowed starting back 12 years ago.

(Oh! And while I'm at it, I'd also like to suggest that aluminum-powder based paint should not be used to coat the outside of the Hindenburg zeppelin, and that the Titanic be outfitted with a bigger rudder.)

Regards, rfg

Hi Ronald, The following does not help you in your quest, but you highlighted one problem in the RIPE Database. It is unfortunately something that has happened many times over over the years in the RIPE Database: "remarks: http://www.ripe.net/db/none-deprecation-042004.html" "remarks: For information on "status:" attribute read https://www.ripe.net/data-tools/db/faq/faq-status-values-legacy-resources, status=LEGACY" "remarks: http://www.ripe.net/db/support/security/domain/syntax.html" "remarks: MD5 passwords older than November 2011 were removed from this maintainer, see: https://www.ripe.net/removed2011pw" "remarks: Auth lines removed by ripe-dbm@ripe.net on 19/8/2002" "remarks: Please see http://www.ripe.net/db/mailfrom.html for explanation" Remarks: attribute being added during a "clean up" or implementation project. They projects are mainly successful but you are then left with lots of "remarks:" trying to explain why and what, many of them with now broken links and no follow up on removing the remarks after X amount of months/years/decades when the information is no longer relevant. One of the more recent and still being added is the "legacy status:" on AS numbers. It is still being added to new AS numbers, even though it has been years since the Status attribute was added to AS numbers. Maybe it is time to stop adding it? And also time to remove it from all objects where it was added? The URL will eventually reach the URL graveyard and will only be there as a reminder that something was done once upon a time with zero information value other than confusion to any users. The other cleanup and implementation URLs are so old that they also make very little sense to still be there in general.

From Job's email.

enroll in the online academy: https://academy.ripe.net

The online courses from the academy are free and open to anyone.

or follow one of the online courses: https://lirportal.ripe.net/training/register/courseCode/WEB20160037 (all dates here: https://lirportal.ripe.net/training/courses)

The training courses in a class are free, but require an active RegID (to be a RIPE NCC member) to signup for you to able to attend. Cheers, David Hilario

Hi Ronald, I'd like to bring to your attention that you can also opt to follow one of the online courses: enroll in the online academy: https://academy.ripe.net or follow one of the online courses: https://lirportal.ripe.net/training/register/courseCode/WEB20160037 (all dates here: https://lirportal.ripe.net/training/courses) All you need is a free RIPE Access account. Kind regards, Job