AS205869, AS57166: Featured Hijacker of the Month, July, 2018
Before I get into talking about this month's honorary Hijacker of the Month, I really must start by thanking everyone who pitched in and helped to insure an appropriate response and outcome for the BitCanal case, which I reported here last month. You all know who you are, and I won't explicitly name you here, only because most of you have expressed to me privately that you would prefer it if I didn't. But you folks deserve the lion's share of the credit, and I, in contrast, played only the most minor supporting role. I must also say that I was astonished and very pleasantly surprised by the very effective and, to-date, very nearly 100% effective response to my call to action with respect to Bitcanal. This thief, Joao Silveira, aka Mr. Bitcanal, and his business are still limping along, and, I'm sure, trying desperately to get back online after everybody with half a brain became convinced of what he has been up to for lo these past several years. He's apparently managed to at least get his main web site (www.bitcanal.com) back online, but now he's totally dependent on GoDaddy hosting for that. :-) I guess that he doesn't have a whole lot of IP space to call his own anymore, or any least not very much of it that he can actually get anyone to route for him. I should also offer my apologies for the rather deliberately rude way that I got right up into the faces of Cogent, GTT, and Level3, right here on the NANOG list, with regards to BitCanal. I see now that that was really rather completely unfair and uncalled for. All three took swift and appropriate action once they became fully aware of the issue/problem, and I am grateful to all of them for their prompt action, and also, of course, I am equally grateful also to the many other providers and IXes who also took appropriate action in this case. Following my posting last month about BitCanal, at least one person rightly took me to task for the rude way I approached the problem, and even moreso for the fact that I escalated the problem to this list as my first response to the whole issue. With 20/20 hindsight, I can now only agree with those criticisms. I shouldn't have done that. I am pleased with the final result, i.e. Bitcanal being kicked from essentially the whole Internet, but the ends do not justify the rather hamfisted means I elected to employ. I will try to do better in future. With that in mind, when I recently found another such operation... another entity performing an entire set of obviously very deliberate hijacks, evidently for the purpose of leasing the hijacked space to snowshoe spammers... I took what I had learned from the BitCanal case and applied it. In particular, rather than me having a very public tantrum and getting on the cases of each and every company that bgp.he.net said might be connected to the hijacker somehow, I instead began by running traceroutes to all of the relevant hijacked blocks. (If I would have had the good sense to have done this in the BitCanal case, I most probably would have begun by just hasseling Cogent alone, and privately, off list, since from where I sit, all of the traceroutes to all the blocks that Bitcvanal stole had Cogent as the next-to-last hop. YMMV) Anyway, in this new case I found that the next-to-last hop for all of the relevant traceroutes was a set of routers belonging to Telecom Italia. Rather than calling them out here, this time I had the good sense to just message TelecomItalia directly about the issue. it took me a couple of tries, but I was eventually able to find a proper contact address for a proper sort of person to discuss this matter with @ Telecom Italia. The two links below are (1) my message to them and (2) their very nice and proactive response back to me: Me -> Telecom Italia https://pastebin.com/raw/Ek3mxKCR Telecom Italia -> Me https://pastebin.com/raw/mtcA4Ehy Given that I sent my message to them well after business hours on Friday, I consider their response, sent on Monday, to be super-fast and very responsive. Of course, I am absolutely ecstatic also that they have elected to stop all routing to the particular bunch of of badness that I explicitly called out to them, at least for the time being. As you can all see, my message to TelecomItalia describes the issue/problem with AS205869 - Universal IP Solution Corp. in some considerable detail. In a nutshell, these guys are criminals and they've been reselling the IPv4 space they've hijacked, specifically but perhaps not only to snowshoe spammers. (Specific evidence available upon request.) Of course, one can easily imagine even vastly worse uses that may be made of stolen IP space. By the time that I personally became aware of what these specific jerks were up to, they had already used, abused, and tossed aside several other IPv4 blocks -and- also a number of other previously abandoned ASNs. (They have been absconding with -both- abandoned IPv4 address blocks -and- also a number of previously abandoned ASNs... as well as one that was/is in active use by its legitimate owner. And they have bee doing so without any apparent restraint watever.) The evidence of all this is crystal clear from a quick review of all of the relevant RIPE records. They left their bloody fingerprints all over this mess. Anyway, by the time I noticed them. late last week, the set of routes and ASNs that this particular set of crooks were still fradulently using were as follows: ASN Route ---------------------- 10510 216.238.64.0/18 10737 207.183.96.0/20 10800 192.110.32.0/19 19529 104.143.112.0/20 19529 198.14.0.0/20 19529 198.32.208.0/20 19529 206.41.128.0/20 30237 192.73.128.0/20 30237 192.73.144.0/20 30237 192.73.160.0/20 30237 192.73.176.0/20 (The above list was present also in my private message to TelecomItalia. See link above.) I suspect that perhaps the fact that the final four routes in the list above are for IPv4 space which is formally registered to the United States Air Force may possibly have contributed somewhat to TelecomItalia's apparent readiness and willingness to take swift and decisive action in this case. (It's not every day that you see USAF IP space being routed by mysterious Ukranian networks. :-) In any case, as I've noted above, I am greatly pleased that TelecomItalia took the action it did, regardless of what factors may have entered into their decision. At this point in my presentation, anyone who might have been expecting another "call to arms", like my posting here last month, will be disappointed. I'd greatly appreciate it if readers of this post would help me to to confirm that the non-routing of the above block is both universal and complete... as it is, at least, from where I am sitting... but at this point I have nothing and nobody to rail against. (Or so I thought! But while writing this post I found some new and apparently associated curiosities relating to a different ASN, AS57166. Read on!) So, anyway with regards to AS205869... case closed? Is it Miller time? Well, yes and no. There's still the question of just who or what the devil is this thing called Universal IP Solution Corp. (which also, apparently, goes by the name of "ADMASTER-MNT" within RIPE WHOIS records). And then there is the question of what there is to prevent these hijackers from just coming back tomorrow under a different guise or corporate identity and starting the game all over again. Even more worrying is the distinct possibility that they may not even find it necessary to change out their current corporate identity before getting back into the game. They could just keep their current name... as BitCanal did... and try to reroute their connectivity via one of their other existing peers. The (ostensible) list of those is shown here: https://bgp.he.net/AS205869#_peers These crooks may have already anticipated the small setback of losing their TelecomItalia connection, and as you can see, they already have nine listed IPv4 peers, although at least four of these are provably ones that they themselves have been masquerading as, specifically: AS11717 Solarus AS7827 American Business Information AS11324 BRFHH Shreveport, LLC AS32226 Menard, Inc. The above ASNs have all been hijacked by the folks using the handle ADMASTER-MNT. The RIPE WHOIS records essentially prove that. (Menard, Inc., by the way, is a chain of retail home improvement stores, comparable to HomeDepot, located in the U.S. MidWest region. Hardly the kind of place you'd expect to be peering with mysterious Ukranian company, -or- to be indirectly routing space... 216.238.64.0/18... for a long-dead Pennsylvania ISP such as Razor, Inc. The case of BRFHH Shreveport, LLC is arguably more worrying than any of the rest of this, because in that case the hijackers apparently didn't even care that the ASN in question was still in active use by its rightful owners, uhsystem.com, which appears to be a University-based hospital in Louisiana. HIPPA horrors easily imaginable!) Anyway, eliminating the ASNs above, we are still left with multiple possible "Plan Bs" for this hijacking operation: AS6762 Telecom Italia <============== plug already pulled AS8359 MTS PJSC (Russia) AS1299 Telia Company AB (Sweden) AS35320 Eurotranstelecom Ltd. (Ukraine) AS57166 D2 International Investment Ukraine Ltd. Now that Telecom Italia has pulled the plug, I'll be emailing to the other peers listed above, and asking them to do likewise. We'll just have to wait and see what they do. But there is one ASN from the above list that I quite definitely -won't- be sending any emails to, and that's the last one, D2 International Investment Ukraine Ltd. AS57166, D2 International Investment Ukraine Ltd. was a name already known to me. It came up previously, right here on this mailing list, in the context of a discussion I had started here on October 5th, 2016 relating to a previous set of hijacks that I had reported here: https://mailman.nanog.org/pipermail/nanog/2016-October/088487.html This thing, whetever it is, has/had a peering relationship, both then and now, with AS29632 Netassist Limited, which is headquartered in... ummm... Ukraine. No. Wait. Make that Gibraltar. Anyway, we'll come back to that a bit latter on. Back in the day, D2 International Investment Ukraine Ltd. was using two different ASNs, i.e. AS43659 and AS57166. As of now, it doesn't seem to be using the former for much of anything: https://bgp.he.net/AS43659 AS57166 is a rather different story however. The listing of IPv4 peers shown currently at bgp.he.net (https://bgp.he.net/AS57166#_peers) shows the following as current peers of AS57166: AS205869 Universal IP Solution Corp. AS29632 Netassist Limited AS11695 TheStreet.Com AS8011 CoreComm Internet Services Inc The first two are (or were) headquartered in Ukraine, so other than the fact that Universal IP Solution Corp. is hip deep in IP address space thievery, those two are unremarkable as peers for D2 International Investment Ukraine Ltd. which is also allegedly located in Ukraine. That third one should come as a bit of a shock to anyone who has ever had the privlege (or misfortune, depending on your point of view) of watching "Mr. Booyah" Jim Cramer attempts to make the muundane world of stock trading entertaining for the masses. TheStreet.com is a highly popular web destination belonging to a company of the same name which was founded by the same said Mr. Jim Cramer. From Wikipedia: TheStreet, Inc. is an American financial news and services website founded by Jim Cramer and Martin Peretz. How does a company like this get mixed up with a bunch of Ukranians of dubious repute?? Well, quite simply they don't. The ASN has been hijacked by AS57166 -- D2 International Investment Ukraine Ltd. As we speak, D2 International Investment Ukraine Ltd. is using this hijacked ASN, AS11695 -- TheStreet.Com for an ongoing set of hijacks, mostly of abandoned legacy IPv4 space belonging to various defunct U.S. companies, but with one Canadian block (69.171.160.0/19) and one Mongolian block (192.82.64.0/19) mixed in just to give this portfolio of hijacks a bit of an international flavor, I suppose. The list of blocks currently announced by AS11695, according to stat.ripe.net, is as follows: 24.137.0.0/20 24.137.0.0/19 24.137.16.0/20 24.236.0.0/19 52.128.192.0/19 66.219.64.0/19 68.232.96.0/20 69.171.160.0/19 70.34.192.0/20 70.34.192.0/19 70.34.208.0/20 98.143.176.0/20 163.123.192.0/20 163.123.192.0/18 163.123.208.0/20 163.123.224.0/20 163.123.240.0/20 192.82.64.0/19 192.254.32.0/19 198.40.192.0/19 204.195.192.0/18 206.15.32.0/19 206.54.128.0/20 206.125.0.0/19 206.127.224.0/19 206.190.160.0/19 206.222.128.0/19 206.246.32.0/19 207.183.64.0/19 209.182.0.0/20 209.182.0.0/18 209.182.16.0/20 209.182.32.0/20 209.182.48.0/20 This is quite an impressive list, even if it does fall a bit short of the recent and slightly more prodigious escapades of Bitcanal. I've run a few traceroutes on a few of the above routes and I've found them to have next-to-last hops within the same batch of Telcom Italia routers as were being used by the batch of hijacks that were easily tracable back to AS205869 - Universal IP Solution Corp. Not a real huge surprise there. AS205869 is peering with AS57166 and vise versa. They are both quite obviously working together on this grand hijacking scheme. Of course, I will shortly be initiating another friendly and, I hope, equally productive chat with my new friend @ Telecom Italia regarding these additional blatant and obvious hijacks. I have so far neglected to mention the forth and final peer of AS57166, i.e. AS8011 -- CoreComm Internet Services Inc. Based on my reading of he relevant RIPE records, this ASN appears to have been registered with RIPE on or about 2017-01-12 by whoever was in control of the RIPE handle "DATASTAR-MNT" as of that date. It appears to me that, with a few exceptions, such as the RIPE WHOIS record for this ASN, pretty much everything else that has been created and installed into the RIPE WHOIS data base by "DATASTAR-MNT" is fundamentally fradulent. Here is the full list of such stuff: https://pastebin.com/raw/DQbWe0gq By extension from this premise, I think that it may be reasonably assumed that any routes currently being announced by AS8011 are most likely also hijacks. As of now, this seems to be limited to only one single route: 216.127.0.0/19. This IPv4 block would seem to have been yet another abandoned IPv4 block that was just left lying around, and which has now been very effectively repurposed in service of the hijackers' preferred ends. Finally, as some may have noted, there is one rather glaring hole in the story it has been presented above, specifically, the true and verifiable identities of the hijackers, which remain cloaked in mystery. D2 International Investment Ukraine Ltd. historically used the domain name etthua.net as part of its contact email address, but that domain currently has no DNS, and data from archives suggests that it may have never had a functioning web site. RIPE NCC undoubtedly has the name of some specific individual to go along with this corporate front name, but even before the advent of the travesty that is GDPR, they almost certainly would refuse to divulge that to any party, based on their traditional strict contractual code of omerta. A page on virustotal seems to suggest a connection of some sort between D2 International Investment Ukraine Ltd. and the now notorious coinhive scam, but it is not at all clear how this connection was derived or even whether there actually is any real connection at all: https://www.virustotal.com/#/ip-address/94.130.90.152 Googling now, I see that I myself called out this crooked enterprise on a RIPE mailing list back on 2016-10-08. (I didn't really remember doing that, as it has been nearly 2 years ago now.) https://www.ripe.net/participate/mail/forum/anti-abuse-wg/PDMxNjk3LjE0NzU5Nj... I also have no specific recollection of this follow-up post by a rather outspoked fellow who goes by the name of Marilson, and who has frequently appeared to drink even substantially more coffee than I do: https://lists.ripe.net/pipermail/anti-abuse-wg/2016-October/003726.html I myself have no direct knowledge of the "Samuel Joel Nirushan" that Marilson spoke of, or about any of Mr. Marilson's specific allegations against him (including that this Mr. Nirushan is even connected in any way to D2 International Investment Ukraine Ltd.) but I did find that if one simply googles for "Samuel Joel Nirushan" or alternatively, for "D2 International Investments" (note: plural, rather than singular) one quickly comes upon a plethora of public postings made by -somebody- who was apparently quite angry at this guy, many most or all of which seem to date from October, 2011, and all of which contain many of the same unsubstantiated allegations of fradulent activities. As these allegations are not accompanied by any relevant documentation, then must be judged to only be worth even less that the electrons they were written on. Arguably more relevant is this archived RIPE WHOIS record that I found online and which appears to show that D2 International Investment Ukraine Ltd. was formerly granted a sub-allocation of IPv4 space which, at that time, and also currently, is registered to NetAssist, Ltd (Ukraine): https://pastebin.com/raw/95LRyvwv This, taken together with the fact that NetAssist, Ltd (AS57166) is currently peering with AS57166 - D2 International Investment Ukraine Ltd., ertainly suggest a strong business relationship between the Netassist and D2, whatever the hell it is. Returning briefly to the other obviously crooked actor in this drama, i.e. AS205869 - Universal IP Solution Corp., it is worth mentioning that this company, like D2 International Investment, also has a domain that is used as part of its contact email address, universalipsolution.bz (BZ -- Belize??) but this domain also, like etthua.net for D2, does not currently have any web site, and based on my reading of historical passive DNS data, it appears that it may have -never- have had one. Nontheless, both D2 International Investments and Universal IP Solution are both members in good standing of RIPE: https://www.ripe.net/membership/indices/data/ua.d2investukraine.html https://www.ripe.net/membership/indices/data/bz.universal.html So, you know, one wonders how these two crooked companies that are clearly colluding together to hijack lots and lots of IP space are then able to somehow turn around and make a profit by selling off bits and pieces of what they have stolen when neither of them even have any web site via which they could entice eager buyers of their stolen property. This is an enigma, but I have a theory that seems at least possible. RIPE provides many useful services to its members, but there is one in particular that I personally have become acquainted with only quite recently. RIPE NCC apparently maintains a list of what they call "Recognised IPv4 Transfer Brokers": https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/brok... As noted on the above page "there are no costs involved" in being admitted to this prestigious and exclusive club, "...however, you will need to agree to adhere to the relevant RIPE Policies and RIPE NCC procedural documents..."
From these public statements of the RIPE web site I infer that as long as one can fog a mirror, and as long as one is willing and able to raise one's right hand and swear on some sort of religious text, one can be and will be admitted into this special club of "recognised" IP brokers.
One company listed on the above page that caught my eye is NetAssist LLC, formerly of Ukraine, but more recently re-incorporated in the jurisdiction of Gibraltar. (Why the company elected to up and change jurisdictions is not immediately obvious.) Whereas neither Universal IP Solution Corp. nor their apparent partners in crime, D2 International Investment Ukraine Ltd. have any web sites, and whereas they both thus have no apparent means of easily reselling/ offloading/fencing any or all of the IP space that the two of them together have stolen, it appears that D2's friend and peer, NetAssist LLC, is already well positioned to barter blocks of IPv4 space that may have unexpectedly gone walkabout. This is not to say that they have done so. I have no direct evidence of that. I just personally find NetAssist's formal registration, with RIPE, as an "recognized" IP broker to be a possibly relevant detail, and one that may perhaps be exceptionally convenient, under the curcumstances. Plesse note that Bitcanal, using its full, formal, and legal name of Ebonyhorizon Telecomunicacoes Lda., is also still a member in good standing of not only RIPE, but also of RIPE's cadre of "Recognised IPv4 Transfer Brokers". (See link above.) To reiterate, I have posted all of this information here on the NANOG list, not as a call to action... I'll be trying myself to contact any and all relevant providers and encouraging them to take appropriate action... but rather just because I felt that people here on this list might want to at least be aware of all of these convoluted shenanigans and schemes. Certainly, I encourage everyone reading this to be extra vigilant, in future, and especially if you are approached in the near future by any Ukrainian (or Gibraltarian) networks requesting peering. Regards, rfg P.S. It is left as an exercise for the reader as to why these sorts of large scale hijacking schemes always seem to originate somewhere within the RIPE geographical region and never elsewhere.
I'd greatly appreciate it if readers of this post would help me to to confirm that the non-routing of the above block is both universal and complete... as it is, at least, from where I am sitting... but at this point I have nothing and nobody to rail against. (Or so I thought! But while writing this post I found some new and apparently associated curiosities relating to a different ASN, AS57166. Read on!)
All prefixes still visible here (Oslo, Norway), through HE. Here's your original table augmented with the AS paths I see on our border routers: ASN Route AS path ----------------------------------------------- 10510 216.238.64.0/18 6939 205869 32226 10510 10737 207.183.96.0/20 6939 205869 7827 10737 10800 192.110.32.0/19 6939 205869 11717 10800 19529 104.143.112.0/20 6939 205869 11324 19529 19529 198.14.0.0/20 6939 205869 7827 19529 19529 198.32.208.0/20 6939 205869 7827 19529 19529 206.41.128.0/20 6939 205869 11324 19529 30237 192.73.128.0/20 6939 205869 11717 30237 30237 192.73.144.0/20 6939 205869 11717 30237 30237 192.73.160.0/20 6939 205869 11717 30237 30237 192.73.176.0/20 6939 205869 11717 30237 Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Dead for me via: HE NTT COX On Tue, Jul 24, 2018 at 3:03 AM, <sthaug@nethelp.no> wrote:
I'd greatly appreciate it if readers of this post would help me to to confirm that the non-routing of the above block is both universal and complete... as it is, at least, from where I am sitting... but at this point I have nothing and nobody to rail against. (Or so I thought! But while writing this post I found some new and apparently associated curiosities relating to a different ASN, AS57166. Read on!)
All prefixes still visible here (Oslo, Norway), through HE. Here's your original table augmented with the AS paths I see on our border routers:
ASN Route AS path ----------------------------------------------- 10510 216.238.64.0/18 6939 205869 32226 10510 10737 207.183.96.0/20 6939 205869 7827 10737 10800 192.110.32.0/19 6939 205869 11717 10800 19529 104.143.112.0/20 6939 205869 11324 19529 19529 198.14.0.0/20 6939 205869 7827 19529 19529 198.32.208.0/20 6939 205869 7827 19529 19529 206.41.128.0/20 6939 205869 11324 19529 30237 192.73.128.0/20 6939 205869 11717 30237 30237 192.73.144.0/20 6939 205869 11717 30237 30237 192.73.160.0/20 6939 205869 11717 30237 30237 192.73.176.0/20 6939 205869 11717 30237
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
In message <20180724.090316.47077931.sthaug@nethelp.no>, sthaug@nethelp.no wrote:
All prefixes still visible here (Oslo, Norway), through HE. Here's your original table augmented with the AS paths I see on our border routers:
ASN Route AS path ----------------------------------------------- 10510 216.238.64.0/18 6939 205869 32226 10510 10737 207.183.96.0/20 6939 205869 7827 10737 10800 192.110.32.0/19 6939 205869 11717 10800 19529 104.143.112.0/20 6939 205869 11324 19529 19529 198.14.0.0/20 6939 205869 7827 19529 19529 198.32.208.0/20 6939 205869 7827 19529 19529 206.41.128.0/20 6939 205869 11324 19529 30237 192.73.128.0/20 6939 205869 11717 30237 30237 192.73.144.0/20 6939 205869 11717 30237 30237 192.73.160.0/20 6939 205869 11717 30237 30237 192.73.176.0/20 6939 205869 11717 30237
Thanks for checking this. I gather from the other posts in this thread that this has already been rectified, and that the above CIDRs are no longer reachable via HE.NET, correct? Even if that's the case, I'm still left scratching my head. There's a bit of a mystery here, or at least something that I don't quite understand. (NOTE: I've never laid claim to being anything like an "expert" when it comes to all this routing stuff. I just muddle along and try to do the best I can with the limited knowledge and understanding that I have.) So, here's what's perplexing me. You reported that all eleven of the routes in the table above had AS paths that directly connected Universal IP Solution Corp. (AS205869) to Hurricane Electric (AS6939). And yet, when I looked at the following page, both yesterday and today, I see no reported connection between those two ASNs: https://bgp.he.net/AS205869#_peers I already knew before now that each of the alleged peerings reported on similar pages on the bgp.he.net web site had to be taken with a grain of salt, mostly or entirely because of the kinds of hanky panky and path forgery being undertaken by various bad guys. In at least some cases, these screwy games appear to have caused bgp.he.net to list peerings that didn't actually exist. But this is a rather entirely different case. In this case, it seems that one very notable peering that -did- in fact exist, between AS205869 and AS6939, was not reported at all on the bgp.he.net page linked to above. To be clear, I most definitely am *not* suggeting any sort of deliberate obfsucation here, on anybody's part. Rather, I just suspect that some of the algorithms that are used to produce the peers lists on bgp.he.net could use some... ah... fine tuning. It certainly seems to be true that in this case, one very important peering was utterly missed by the algorithms that power bgp.he.net. Regards, rfg
radar.qrator.net serves as a complementary view to bgp.he.net and AS205869 does show as peered with AS6939 there. Jason On Tue, Jul 24, 2018 at 3:02 PM Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
In message <20180724.090316.47077931.sthaug@nethelp.no>, sthaug@nethelp.no wrote:
All prefixes still visible here (Oslo, Norway), through HE. Here's your original table augmented with the AS paths I see on our border routers:
ASN Route AS path ----------------------------------------------- 10510 216.238.64.0/18 6939 205869 32226 10510 10737 207.183.96.0/20 6939 205869 7827 10737 10800 192.110.32.0/19 6939 205869 11717 10800 19529 104.143.112.0/20 6939 205869 11324 19529 19529 198.14.0.0/20 6939 205869 7827 19529 19529 198.32.208.0/20 6939 205869 7827 19529 19529 206.41.128.0/20 6939 205869 11324 19529 30237 192.73.128.0/20 6939 205869 11717 30237 30237 192.73.144.0/20 6939 205869 11717 30237 30237 192.73.160.0/20 6939 205869 11717 30237 30237 192.73.176.0/20 6939 205869 11717 30237
Thanks for checking this. I gather from the other posts in this thread that this has already been rectified, and that the above CIDRs are no longer reachable via HE.NET, correct?
Even if that's the case, I'm still left scratching my head. There's a bit of a mystery here, or at least something that I don't quite understand. (NOTE: I've never laid claim to being anything like an "expert" when it comes to all this routing stuff. I just muddle along and try to do the best I can with the limited knowledge and understanding that I have.)
So, here's what's perplexing me. You reported that all eleven of the routes in the table above had AS paths that directly connected Universal IP Solution Corp. (AS205869) to Hurricane Electric (AS6939). And yet, when I looked at the following page, both yesterday and today, I see no reported connection between those two ASNs:
https://bgp.he.net/AS205869#_peers
I already knew before now that each of the alleged peerings reported on similar pages on the bgp.he.net web site had to be taken with a grain of salt, mostly or entirely because of the kinds of hanky panky and path forgery being undertaken by various bad guys. In at least some cases, these screwy games appear to have caused bgp.he.net to list peerings that didn't actually exist.
But this is a rather entirely different case. In this case, it seems that one very notable peering that -did- in fact exist, between AS205869 and AS6939, was not reported at all on the bgp.he.net page linked to above.
To be clear, I most definitely am *not* suggeting any sort of deliberate obfsucation here, on anybody's part. Rather, I just suspect that some of the algorithms that are used to produce the peers lists on bgp.he.net could use some... ah... fine tuning. It certainly seems to be true that in this case, one very important peering was utterly missed by the algorithms that power bgp.he.net.
Regards, rfg
But this is a rather entirely different case. In this case, it seems that one very notable peering that -did- in fact exist, between AS205869 and AS6939, was not reported at all on the bgp.he.net page linked to above.
HE usually learn these hijacked routes from IX peering and route servers. bgp.he.net tends not to report on IX peering. To their credit, HE have an extremely open peering policy. To their detriment, this means their customers see the large majority of hijacked routes due to poor filtering on many IX route servers.
Hi Ronald,
From your initial list, I can still see some prefixes with the NLnog ring :
http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=206.41.128.0 http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=52.128.192.0 http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv4?q=206.222.128.0 Also http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv4?q=94.130.90.152 Best regards,
On Wed, Jul 25, 2018 at 12:58:46PM +0200, Jérôme Nicolle wrote:
From your initial list, I can still see some prefixes with the NLnog ring :
http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=206.41.128.0 http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=52.128.192.0 http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv4?q=206.222.128.0
Also http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv4?q=94.130.90.152
If I have to guess, those probably are ghost or stale routes. Wouldn't worry about them. I've noticed that quite a bunch of networks that use "BGP optimisers" end up reporting having certain routes to the NLNOG LG while in reality those were withdrawn globally. Kind regards, Job
participants (7)
-
Dovid Bender
-
Jason Alderfer
-
Job Snijders
-
Jérôme Nicolle
-
Phil Lavin
-
Ronald F. Guilmette
-
sthaug@nethelp.no