Hi, On Sun, Nov 16, 2014 at 07:32:25PM -0800, Ronald F. Guilmette wrote:
Based upon the information I am currently looking at (see below) I now believe that it was perhaps a mistake for myself, and possibly others, to have become focused on the issue of insuring the correctness and/or validity of route objects within the RIPE data base only in those cases where the IP blocks in question are under the dominion of other (non-RIPE) RiRs.
It now seems certain to me that the absence of anything even remotely approximating proper validation of RIPE route objects is not, in fact, a problem which is limited to just inter-RiR situations. Apparently, RIPE member LIRs can just as easily hijack the IP blocks of other RIPE members as they can in the case of IP blocks belonging to parties in other regions.
Well, there's two aspects to it: - hijacking blocks when the upstream ISP builds a BGP prefix filter from the RIPE IRR DB -> this can be done of out-of-region networks but not for in-region networks (unless someone is careless with their password), and something can be done about it by the RIPE NCC (with a mandate from one of these working groups) - hijacking blocks when the upstream ISP just accepts and forwards anything the customer announces by BGP -> this must be stopped at the ISP, and the RIPE NCC can't really do something about it. OTOH, the operator community should apply peer pressure here - as in: "dear ISP, if you continue to announce unfiltered prefixes from your customers, this is violating our AUP and we'll shutdown *your* link to us".
Also, RIPE-resident hijackers can just as easily place validating route objects for these hijacked RIPE-issued IP blocks into the RIPE DB as they can for any other hijacked blocks taken from any other region(s).
No... the RIPE DB prevents route: objects for RIPE (NCC-issued) networks by checking the maintainer authentication for inetnum: and aut-num: - so unless the address holder is careless ("pick a 5 character easily guessable password" or "reference a well-known maintainer") it is much harder to do, if not impossible. Now, I hear what you're saying and I look at 188.229.1.0/24 and wonder what has happened, and why "whois --list-versions" isn't showing me the update/creation history for the /24 route... Ah. Now this is an interesting example of "history" in the RIPE database: gert@moebius3:/home/gert$ whois3 --show-version 4 188.229.0.0/17 % Version 4 of object "188.229.0.0 - 188.229.127.255" % This version was a UPDATE operation on 2011-09-07 20:15 % You can use "--list-versions" to get a list of versions for an object. inetnum: 188.229.0.0 - 188.229.127.255 netname: RO-NETSERV-20090729 descr: Netserv Consult SRL ... mnt-routes: NETSERV-MNT so, that /17 had, at some point in time, mnt-routes: pointing to NETSERV-MNT. gert@moebius3:/home/gert$ whois3 --show-version 5 188.229.0.0/17 % Version 5 (current version) of object "188.229.0.0 - 188.229.127.255" % This version was a UPDATE operation on 2014-10-27 15:06 % You can use "--list-versions" to get a list of versions for an object. inetnum: 188.229.0.0 - 188.229.127.255 netname: IR-MCI-20090729 descr: Mobile Communication Company of Iran PLC ... mnt-routes: MCCI-MNT So, in October 2014, the entry was changed to "mnt-routes: MCCI-MNT", which prevents creating of route: objects unless you have the proper auth codes. Now, looking at the route: route: 188.229.1.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT changed: ripe@netserv.ro.REMOVE 20130820 source: RIPE ... it claims to have been created in the time between (changed: is not authoritative, but in this case looks plausible). Checking object versions 1-4, it seems that this netblock was originally given to Netserv, and then either sold to Iran, or withdrawn by the NCC and reallocated to Iran (the published transfer statistics would clarify this), but when that happened, the route: objects were not removed - so, even when that network was no longer with Netserv, their route: objects were still there. This should not happen, of course, but it's not a technical weakness in the RIPE DB (*phew*) but human mistake. MCCI should really, really clean up all route objects that cover parts of their address space but point to other origin ASes. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279