This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] Puzzled by RIPE-NCC-LOCKED-MNT
- Previous message (by thread): [db-wg] Puzzled by RIPE-NCC-LOCKED-MNT
- Next message (by thread): [db-wg] Puzzled by RIPE-NCC-LOCKED-MNT
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ronald F. Guilmette
rfg at tristatelogic.com
Mon Nov 21 02:46:19 CET 2016
In message <1516ae60-4249-ac9d-05e5-dbce3845544b at ripe.net>, Rene Wilhelm <wilhelm at ripe.net> wrote: >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: Ahhhhhh! Got it now. Thanks. This is VERY helpful. >... >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. 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 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? 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? 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) 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
- Previous message (by thread): [db-wg] Puzzled by RIPE-NCC-LOCKED-MNT
- Next message (by thread): [db-wg] Puzzled by RIPE-NCC-LOCKED-MNT
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]