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. 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). Readily available public data indicates that approximately three weeks ago, on or about October 25th, AS197207, an Iranian ISP, began announcing the following routes to the following chunks of its own properly registered IP space: 31.2.128.0/17 46.51.0.0/17 95.64.0.0/17 164.138.128.0/18 188.229.0.0/17 Prior to AS197207's decision to begin announcing the above routes (which they did, starting on Oct. 25th), it appears that the proprietors of AS43890, a Romanian ISP and RIPE LIR in good standing, apparently elected to announce their own set of routes to some or all of the above Iranian IP blocks, using lots and lots of little deaggregated /24 announcements to do so. Evidence in my possession indicates that some of the /24 blocks in question were in fact used by so-called ``snowshoe spammers'' during the time when AS43890 (aka "Netserv Consult SRL") was routing these blocks. This fact leads me to believe that the proprietor(s) of AS43890 most probably did not in fact have anything like real authorization from AS197207 to announce routes to any of the Iranian AS197207's legitimately registered IP space. Further and additionally, as in the recent case involving (Bulgarian) AS201640, it appears that (Romanian) AS43890 also and likewise created multiple route objects within the RIPE data base as a way of legitimizing what appears to me to have been several substantial IP space hijackings. Lastly, many, most, or all of the fradulent route objects created by AS43890 are still present within the RIPE data base, as of today. I am including a list of all 61 of these below. As was the case with the fradulent route objects created within the RIPE DB by AS201640, these 61 apparently fradulent route objects which were created by the proprietor(s) of AS43890 have likewise also been imported into the MERIT RADb, from the RIPE DB, thus spreading the bogus ``authorization'' to route these blocks even further, in a manner not unlike a viral contaminant. Regards, rfg ======================================================================= route: 188.229.1.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.2.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.3.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.9.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.11.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.16.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.17.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.18.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.19.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.20.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.21.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.22.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.23.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.33.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.35.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.36.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.38.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.39.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.49.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.50.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.51.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.52.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.53.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.54.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.55.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.66.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.89.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.90.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.91.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.92.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.93.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.94.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.95.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.96.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.97.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.98.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.99.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.100.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.101.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.102.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.103.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.104.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.105.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.106.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.107.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.108.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.109.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.110.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.111.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.113.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.114.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.117.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.118.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.119.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.120.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.121.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.122.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.123.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.124.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.125.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.126.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered
Hi Ronald,
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.
I don't think so... To be able to create the route object route: 188.229.1.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE Authorisation from both the address block inetnum: 188.229.0.0 - 188.229.63.255 netname: LTE-4G descr: new service for data country: IR admin-c: RL7844-RIPE tech-c: RL7844-RIPE status: ASSIGNED PA mnt-by: MCCI-MNT source: RIPE and the AS number aut-num: AS43890 as-name: NETSERV-AS descr: Netserv Consult SRL [...] org: ORG-SNCS6-RIPE status: ASSIGNED mnt-by: NETSERV-MNT mnt-by: RIPE-NCC-END-MNT mnt-routes: NETSERV-MNT source: RIPE is required. So the route cannot be created unless MCCI-MNT and NETSERV-MNT both authorise it. I understand that the route objects look a little weird, but what makes you think that it is an authorisation problem in the RIPE DB that made it possible for someone to create them? Cheers, Sander
On Mon, Nov 17, 2014 at 11:21:23AM +0300, Sander Steffann wrote:
Hi Ronald,
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.
I don't think so...
To be able to create the route object
route: 188.229.1.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE
Authorisation from both the address block
inetnum: 188.229.0.0 - 188.229.63.255 netname: LTE-4G descr: new service for data country: IR admin-c: RL7844-RIPE tech-c: RL7844-RIPE status: ASSIGNED PA mnt-by: MCCI-MNT source: RIPE
and the AS number
aut-num: AS43890 as-name: NETSERV-AS descr: Netserv Consult SRL [...] org: ORG-SNCS6-RIPE status: ASSIGNED mnt-by: NETSERV-MNT mnt-by: RIPE-NCC-END-MNT mnt-routes: NETSERV-MNT source: RIPE
is required. So the route cannot be created unless MCCI-MNT and NETSERV-MNT both authorise it.
The assignment of 188.229.0.0/17 to mci.ir is relatively recent, probably issued: changed: hostmaster@ripe.net 20141027 Previously it was inetnum: 188.229.0.0 - 188.229.127.255 netname: RO-NETSERV-20090729 descr: Netserv Consult SRL country: RO org: ORG-NCS8-RIPE admin-c: MINC-RIPE tech-c: NSC-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: NETSERV-MNT mnt-routes: NETSERV-MNT mnt-domains: NETSERV-MNT remarks: ------------------------------------ remarks: | Abuse e-mail: abuse@netserv.ro | remarks: | Support e-mail: support@netserv.ro | remarks: | Support phone: 4-0745888222 | remarks: ------------------------------------ and it indeed appeared to be leased to snowshoe spammers in its entirety. Similarly, inetnum: 31.2.128.0 - 31.2.255.255 netname: RO-NETSERV-20110405 descr: NETSERV CONSULT SRL country: RO org: ORG-NCS8-RIPE admin-c: MINC-RIPE tech-c: NSC-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: NETSERV-MNT mnt-routes: NETSERV-MNT mnt-domains: NETSERV-MNT remarks: ------------------------------------ remarks: | Abuse e-mail: abuse@netserv.ro | remarks: | Support e-mail: support@netserv.ro | remarks: | Support phone: 4-0745888222 | remarks: ------------------------------------ inetnum: 46.51.0.0 - 46.51.127.255 netname: RO-NETSERV-20100727 descr: Netserv Consult SRL country: RO org: ORG-NCS8-RIPE admin-c: MINC-RIPE tech-c: NSC-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: NETSERV-MNT mnt-routes: NETSERV-MNT mnt-domains: NETSERV-MNT remarks: ------------------------------------ remarks: | Abuse e-mail: abuse@netserv.ro | remarks: | Support e-mail: support@netserv.ro | remarks: | Support phone: 4-0745888222 | remarks: ------------------------------------ inetnum: 95.64.0.0 - 95.64.127.255 netname: RO-NETSERV-20081023 descr: Netserv Consult SRL country: RO org: ORG-NCS8-RIPE admin-c: MINC-RIPE tech-c: NSC-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: NETSERV-MNT mnt-routes: NETSERV-MNT mnt-domains: NETSERV-MNT remarks: ------------------------------------ remarks: | Abuse e-mail: abuse@netserv.ro | remarks: | Support e-mail: support@netserv.ro | remarks: | Support phone: 4-0745888222 | remarks: ------------------------------------ inetnum: 164.138.128.0 - 164.138.191.255 netname: RO-NETSERV-20120319 descr: NETSERV CONSULT SRL country: RO org: ORG-NCS8-RIPE admin-c: MINC-RIPE tech-c: NSC-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: NETSERV-MNT mnt-routes: NETSERV-MNT mnt-domains: NETSERV-MNT remarks: ------------------------------------ remarks: | Abuse e-mail: abuse@netserv.ro | remarks: | Support e-mail: support@netserv.ro | remarks: | Support phone: 4-0745888222 | remarks: ------------------------------------ So a possible scenario is that MCI.ir was in real need for IPv4 space, went on the market, found Netserv that had plenty of it unused (sort of) and made a deal with them. furio
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Apologies for wading into something that isn't my area, but I just noticed Friday's story on the Register: http://www.theregister.co.uk/2014/11/14/dormant_web_space_ripe_for_hijacking... On 17/11/14 08:21, Sander Steffann wrote:
Hi Ronald,
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.
I don't think so...
As a routing newbie, I'd appreciate clarification on what exactly *is* different between the case where the inetnum and the ASN are both allocated by RIPE, and an "inter-RIR" route. And *should* anything be different?
To be able to create the route object
route: 188.229.1.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE
Authorisation from both the address block
inetnum: 188.229.0.0 - 188.229.63.255 netname: LTE-4G descr: new service for data country: IR admin-c: RL7844-RIPE tech-c: RL7844-RIPE status: ASSIGNED PA mnt-by: MCCI-MNT source: RIPE
and the AS number
aut-num: AS43890 as-name: NETSERV-AS descr: Netserv Consult SRL [...] org: ORG-SNCS6-RIPE status: ASSIGNED mnt-by: NETSERV-MNT mnt-by: RIPE-NCC-END-MNT mnt-routes: NETSERV-MNT source: RIPE
is required. So the route cannot be created unless MCCI-MNT and NETSERV-MNT both authorise it.
Such has been my limited experience with administering the RIPEdb: the object isn't published until identical ones are added by the maintainer of the netblock and the maintainer of the ASN. So is not the RIPE database of prefixes itself relatively secure even without RPKI? Do we think the authorisation for MCCI-MNT has been compromised? Is the absence of a "mnt-routes" attribute in the netblock significant? And even without this object: % Information related to '188.229.16.0/24AS43890' route: 188.229.16.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered What is to prevent AS43890 (or something claiming to be AS43890) advertising this prefix via BGP? What action *can* RIPE take?
I understand that the route objects look a little weird, but what makes you think that it is an authorisation problem in the RIPE DB that made it possible for someone to create them?
Cheers, Sander
Thanks for everyone's work on this, and for future clarifications. Back to lurking... - -- All best wishes, Cedric Knight -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUabeMAAoJEN5s/jLcInyImj8P/2O99AajMeIW9t8t/BSaP6lu HKV2MgnICF1iAHrizENXLNm1WxwwO8I2EJrw1PDO7KsDoUfe2QoZd1IZf5RrzLH/ qWn8fBTWNeTY/n6hpEAhbVOjKfhM+iFbqEEyWkCQr/5kZGZDiJruFWDVABoFqv8S pw646gjoUyUJgDtdP1il3b73QCZLF26tElRdce0YA2XfGmNHTc1IYYPHyRXtVXvq DfqdDeadLte3AkN2AQPPiSYoAJPnxIqer+GwW5+wP+54PoHhDISKQuZK5l1JGj7O wwiof4fxiRWNEQybrrQ8kJKjwDijfwgzy5vDcCWvg5/s2FWNYU2twGBcl8XMu8HM TBzW3A6PCFTqeLtqctNHmLDlDozGiYRp8L4Nebsw7wIu2Meo1jycBUpjzC2+ukOY cgv8T6IfqgCkge3bf48fqs54QRiE/dROtZAiH4JLg9aKnr8UbNGAtEZMOAmKmwxl lOesKf/e8cUyVKFKEJwkT/xATOjGFHYsIgMv2sLNyh9kbffkbP5s7w1LDihMnCgW UEEa6+35PRXZxd5IdUpCElScVxB0zskihzIz0tCHhVEXNza50Gb56z0aMOO0yU3l JZFM5kyFxsjTy2LY5Ce6cVos/1XyUOu4wLVQ89uXVnsfrJiEZ8Ils21fUneFfeLn THtpD4DQZsxVeegcaCP2 =DoVE -----END PGP SIGNATURE-----
In message <BE0B5059-0051-46B5-8349-039D37F3151A@steffann.nl>, Sander Steffann <sander@steffann.nl> wrote:
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.
I don't think so...
You're right, and I apologize to everyone for the false alarm. I made a mistake. It's that simple. I looked at the wrong changed: field and concluded that the Iranians had had the containing block (188.229.0.0/17) since 20120905. But now I see that that was incorrect, and the Iranians had most probably only been assigned this block very very recently, e.g. 20141028. Obviously, that changes the analysis completely. There was no hijacking here. None at all. I apologize that I misspoke. That having been said, the fact that all of those 61 now-clearly-stale route objects remain in the data base is, I would say, rather obviously un-good. I understand that it was, it the first instance, the responsibility of netserv.ro to have removed those, but clearly, they didn't. Perhaps we could (or should) talk about some automated procedures that might automagically remove such bogus/stale cruft, even in the absence of prompt action by the parties who created the object in the first place. Regards, rfg
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
On Mon, Nov 17, 2014 at 09:46:33AM +0100, Gert Doering wrote:
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...
You need to query as following to retrieve the history of route objects: $ whois -h whois.ripe.net -- '--list-versions 188.229.1.0/24AS43890'
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).
The history lists: "1 2014-05-12 18:23 ADD/UPD" Kind regards, Job
Hi, On Mon, Nov 17, 2014 at 10:53:09AM +0100, Job Snijders wrote:
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...
You need to query as following to retrieve the history of route objects:
$ whois -h whois.ripe.net -- '--list-versions 188.229.1.0/24AS43890'
Ah! Thanks for that.
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).
The history lists: "1 2014-05-12 18:23 ADD/UPD"
So the changed: is bogus, but the time frame still matches (route: created in May 2014, netblock transferred in October 2014). So I'll call this "operator error". Plus maybe "bad advice by the broker coaching the transfer"... 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
In message <20141117084633.GA20482@Space.Net>, Gert Doering <gert@space.net> wrote:
MCCI should really, really clean up all route objects that cover parts of their address space but point to other origin ASes.
Wait, so you are saying that the *Iranians* should be responsible for cleaning up the mess that was left behind by their predecessors, i.e. the folks who had the 188.229.0.0/17 block before the Iranians did?? Can they even remove those route objects, given that they didn't even create them in the first place? Can any arbitrary RIPE member remove route objects that were created by any other RIPE member? Regards, rfg
Hi, On Mon, Nov 17, 2014 at 01:16:08PM -0800, Ronald F. Guilmette wrote:
In message <20141117084633.GA20482@Space.Net>, Gert Doering <gert@space.net> wrote:
MCCI should really, really clean up all route objects that cover parts of their address space but point to other origin ASes.
Wait, so you are saying that the *Iranians* should be responsible for cleaning up the mess that was left behind by their predecessors, i.e. the folks who had the 188.229.0.0/17 block before the Iranians did??
Well, it should be part of the purchase contract - "we buy this block under the condition that... and only pay if this is all fulfilled". In any case it is partly their responsibility to check that there is nothing lingering.
Can they even remove those route objects, given that they didn't even create them in the first place?
Can any arbitrary RIPE member remove route objects that were created by any other RIPE member?
Generally speaking, no. Routes that point to parts of *your* address space, you can remove, if I remember right - because normally you need to approve the creation anyway (by authorizing the update). I need to find the flow chart on the RIPE web site that precisely describes which authorization is checked where, but if I remember right, for deletion, the "mnt-routes:" (fallback to mnt-by: if no mnt-routes:) authorization on the inetnum is sufficient for removal. 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
Gert Doering wrote:
Hi, [...]
Can any arbitrary RIPE member remove route objects that were created by any other RIPE member?
Generally speaking, no.
Generally speaking, in order to delete an objecct, you need the same (set of) credentials you would need to create or modify the object. As you correctly point out, there are a couple of exceptions to prevent dead- lock situations when one party fails to cooperate. Removing a route object is one of those, iirc; deleting a revDNS delegation entry is another.
Gert Doering -- NetMaster
Wilfried
On Sun, Nov 16, 2014 at 07:32:25PM -0800, Ronald F. Guilmette wrote:
31.2.128.0/17 46.51.0.0/17 95.64.0.0/17 164.138.128.0/18 188.229.0.0/17
Prior to AS197207's decision to begin announcing the above routes (which they did, starting on Oct. 25th), it appears that the proprietors of AS43890, a Romanian ISP and RIPE LIR in good standing, apparently elected to announce their own set of routes to some or all of the above Iranian IP blocks, using lots and lots of little deaggregated /24 announcements to do so.
Try to compare: ftp://ftp.ripe.net:/ripe/stats/2014/delegated-ripencc-20141026.bz2 with ftp://ftp.ripe.net:/ripe/stats/2014/delegated-ripencc-20141027.bz2 looking for a change apply to 188.229.0.0/17 instead of drawing some (most probably) invalid conclusions. This page should also be very helpful: http://www.ripe.net/lir-services/resource-management/ipv4-transfers/table-of... Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
participants (8)
-
Cedric Knight -
furio ercolessi -
Gert Doering -
Job Snijders -
Piotr Strzyzewski -
Ronald F. Guilmette -
Sander Steffann -
Wilfried Woeber