- Test - lists.nanog.org

Jenkins amplification
by Töma Gavrichenkov 04 Feb '20

04 Feb '20

FYI https://nvd.nist.gov/vuln/detail/CVE-2020-2100 A nice description: https://mobile.twitter.com/Foone/status/1223063275996213248 May you live in interesting times. Do not postpone a software update if Jenkins is deployed somewhere in your network. -- Töma

13 19

Help with survey on enterprise network challenges?
by Joseph Severini 04 Feb '20

04 Feb '20

Hi, My name is Joseph Severini, and I am a PhD student in the Computer Science Department at Carnegie Mellon University. I’m working on a research project to identify common operational challenges in modern enterprise computer networks. I’ve put together a survey to identify these challenges by analyzing some operational problems found in the Network Engineering Stack Exchange open-source dataset. You’ll be given a problem from the dataset and asked some questions about it. I would appreciate it if you would consider taking this survey, which can be found at the link below: http://cmu.ca1.qualtrics.com/jfe/form/SV_dm6i9znuPWlLDN3 The survey should take ~15 minutes. Participation is voluntary, with no compensation, and all responses are anonymous. You must be at least 18 years old to complete the survey. Thanks, Joseph Severini PhD Student CMU Computer Science Department

1 0

WTR: 1-2RU @ Equinix Ashburn
by Jason Lixfeld 04 Feb '20

04 Feb '20

Hi, I’m wondering if anyone is looking to subsidize their Equinix Ashburn colo costs by way of carving out 1-2 RU to a friendly for a low density networking application. If so, I’d love to hear from you! Thanks in advance!

1 0

EVPN multicast route (multi home case ) implementation / deployment information
by Mankamana Mishra (mankamis) 04 Feb '20

04 Feb '20

Folks Wondering if there is any known implementation of EVPN multihome multicast routes which are defined in https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-04 there is some change planned in NLRI , we want to make sure to have solution which does work well with existing implementation. Note: Discussion involves Nokia, Juniper, Cisco, Arista already. So looking for any other vendor who have implementation. Mankamana

2 1

Recommended DDoS mitigation appliance?
by Rabbi Rob Thomas 04 Feb '20

04 Feb '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, NANOG! I'm in the midst of rebuilding/upgrading our backbone and peering - sessions cheerfully accepted :) - and am curious what folks recommend in the DDoS mitigation appliance realm? Ideally it would be capable of 10Gbps and circa 14Mpps rate of mitigation. If you have a recommendation, I'd love to hear it and the reasons for it. If you have an alternative to an appliance that has worked well for you (we're a mix of Cisco and Juniper), I'm all ears. Private responses are fine, and I'm happy to summarize back to the list if there is interest. Thank you! Rob. - -- Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree." - Leo McKern -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAl3Rx08ACgkQQ+hhYvqF 8o0snw/8CxTOujcodNh/huMXZaUNlMNoNRz3IoPqBiAP9BZomMz9xqlpDW/qvWBF xhoJ07C0O0mo5ilNjnPR308uifIBu6ylw02PshOCU06dV0afgtndxGg5AoG9npUV 7uCi2afWaf22dq5TwKLut8QPNNQJTRzndX88xJw9MzzoBTemxRtM7ft4H3UhJ0hv oKo83FCNZQt36I+GZA9GBJeXM+o0f5h0w6fhRqARzttf6brJZdXgROyIQ7jptGuZ N3Yrjk/8RM4XKMnYbtIwl8NS3c0nEGN3ndn+Bz7p2FE7QJrZKonk/o03dvr2kU0Y 7gUQliOOzV9EsptVGyLCVyDJSElvXTBaps0giEVZhdmEIDJPWvBc+93j1g7xbmti 27lT6+5qBmEN0oKJWxXgtw9/n1yX9vsc7tXlgYDoXGhIlszdB3baRao1tYEp8BBQ hTGAULRfHe94tRzvOOQUQIuhzNcK1Q4E2jU6kzBB1wJsBD4zuHk+QIJLSHBmmnka VNKlQ+5zP8dmSMBp6k4feqAtt3hy0Bj+34FbdQZYPutIe3VXHEjpWI3jI9vKjhtC g7U/9CQIjVUl2APn1IllArpUpETBlNq7dSeJNUN/4Xh+eHglUnEn/m2kFG5mizmP d0YvLEVe0/+WzDUz+y3KxDVP5tdJT1VM46FHIgeiB4KrWNGRPUo= =uuel -----END PGP SIGNATURE-----

18 30

The curious case of 159.174.0.0/16
by Ronald F. Guilmette 03 Feb '20

03 Feb '20

[[ Fair warning to newcomers: I write and post longish pieces here regarding my various investigations of funny business I find going on within the IPv4 address space and the allocations and uses thereof. If you're looking for a quick 2 minute read then you are advised to skip this message now. ]] I confess that I have been meaning to write about the 159.174.0.0/16 legacy IPv4 block for quite some time now. What can I say? I was busy. The Present State of 159.174.0.0/16 ----------------------------------- I discovered quite some long time ago that this block was getting routing from a rather unusual place, and that the ASN in question was also announcing a few other nice juicy /16 legacy blocks, which by itself was more than a little suspicious. But that's not imporant now. Please allow me to just talk about who is routing this block at present, and who the alleged legitimate registrants are, going by ARIN's relevant current WHOIS record for this block: https://pastebin.com/raw/FBWMN9p3 As you can see, this block is registered to an entity located in Wilton, Connecticut. The block appears to have been originally assigned on 1992-05-11, well before the formation of ARIN. It is thus an unusually valuable "legacy" block. The first indication that something might be a bit off about this block is the contact phone number, +1-407-476-9854. In this modern era of number portability the area code portion of that may or may not have any real-world geographical implications at all, but it turns out to be notable, in this case, that area code 407 corresponds, historically, to the greater Orlando, Florida area and surrounding Florida counties. A quick bit of research reveals that there is in fact an entity calling itself Dunsnet, LLC and that it is located in Winter Park, Florida, a northern suburb of Orlando: http://search.sunbiz.org/Inquiry/CorporationSearch/SearchResultDetail?inqui… Further research on the Florida Secretary of State's web site confirms that this entity does exist, that it is "active", and that it has one and only one manager, that being another corporate entity called Ahosting, Inc.: http://search.sunbiz.org/Inquiry/CorporationSearch/SearchResultDetail?inqui… As you can see via the above link, Ahosting, Inc. has only two corporate directors, i.e. a Mr. Erkan Ozdogan and a Mr. Adnan Canturk, both apparently residents of Istanbul, Turkey. At the present time, 100% of the 159.174.0.0/16 legacy block is being routed by AS54163, aka Ahosting, Inc.: https://bgp.he.net/AS54163#_prefixes The question is: Is this proper? A Brief History of 159.174.0.0/16 --------------------------------- When the 159.174.0.0/16 block was first allocated and registered, way back on 1992-05-11 it was assigned at that time to a unit of the famous Dun & Bradstreet financial information company for use in connection with one of the company's early forays into the world of the Internet: Fortune Magazine, August 19, 1985: https://archive.fortune.com/magazines/fortune/fortune_archive/1985/08/19/66… "Dun & Bradstreet also operates DunsNet, a $20- million private telecommunications network completed in March, which connects customers in 155 cities directly to the company's mainframes." On June 8th, 1994, Dun & Bradstreet's "Dunsnet" operation announced that it had elected to partner with a European company named Eunetcom SA, which was itself a partnership between Deutsche Bundespost Telekom and France Telecom: https://www.cbronline.com/news/eunetcom_wins_dunsnet_pact/ In August, 1994, Eunetcom apparently elected to buy out its customer, Dunsnet: "The Information Superhighway" (Randall L. Carlson - 1996) https://bit.ly/2O7kV48 "Eunetcom is actively pursuing customers and entry into the North American market. Its first customer was worth $200 million over five years and was {subequently} acquired by purchasing the networking services of Dun & Bradstreet's DunsNet. DunsNet provides data communications services for the Dun & Bradstreet companies, a role that Eunetcom now assumes." https://www.postjobfree.com/resume/pumacu/unix-administrator-technical-anal… "In August 1994, DunsNet was acquired by eunetcom, a joint venture between Deutsche Telekom and France Telecom." As we all know, unlike the situation today, IPv4 blocks in the 1990s had essentially no monetary value. And thus the 159.174.0.0/16 block became forgotten and abandoned by its rightful owners, which is to say Deutsche Telekom and France Telecom. Fast forward some 16 years to June 29, 2011, on which date it appears that two clever fellows in Istanbul, Turkey began what would seem to be a quite deliberate, premeditated, and determined effort to take control of the (now quite valuable) 159.174.0.0/16 legacy block via the same sort of simple-minded ruse that had already, by that time, worked so well for others who likewise coveted various ARIN-administered large and valuable legacy IPv4 blocks. They simply pretended to be "Dunsnet" and began the process of requesting from ARIN complete control over "their" legacy block. ARIN apparently obliged and permitted these two Turkish geentleman to make various changes to the relevant ARIN WHOIS records. The official ARIN "WhoWas" historical records relating to the 159.174.0.0/16 block show quite clearly various changes being made to the relevant organization record on 06-29-2011, 09-24-2011, and again on 11-06-2017: https://pastebin.com/raw/WTgvjXg2 Also and similarly, changes were made to the NET-159-174-0-0-1 record for the block itself on 06-29-2011 and again on 11-06-2017: https://pastebin.com/raw/b3F1eTua These latter day changes to the relevant ARIN WHOIS records might have been and remained mostly unsuspicious had it not been for the creation, by the aforementioned two Turkish gentlemen, on 08/06/2012, of the new Florida LLC named "Dunsnet, LLC". (See link above.) In this context, it seems more than plausible that the name of this newly minted Florida LLC was chosen specifically and deliberately with the intent of hiding the facts regarding the illicit usurpation of the valuable 159.174.0.0/16 block. This pattern of apparent corporate-level identity theft is one that I have already seen on multiple previous occasions in association with fraud, perpetrated against some Regional Internet Registry (and ARIN in particular) with the goal being the theft of some sizable IPv4 legacy block. In fact, the only thing that is actually striking and somewhat remarkable in this case is the exact timing of the relevant events. As noted above, the relevant ARIN WHOIS records were, it appears, improperly fiddled on various dates in 2011. It is not immediately clear why ARIN would have allowed such manipulations in that year, given that the fradulent Florida shell company, Dunsnet, LLC was not actually incorporated until 08/06/2012 according to Florida state records. (See link above.) As noted above, official Florida state records for Dunsnet, LLC say that it has one and only one manager, that being Ahosting, Inc. As also noted above, two specific persons appear to be in control of Ahosting, Inc., Mr. Erkan Ozdogan and Mr. Adnan Canturk, both residents of Istanbul, Turkey. Despite the strikingly inconvenient commute that these two gentlemen must apparently have to deal with, these gentlemen quite obviously are the principals of at least the two Florida corporate entities named above. A look at some relevant web sites provides us with some further clues. Whereas ahosting.com formerly was associated with a fuilly functioning web site, that appears to not be the case at the present time. There is some downloadable content that can be reached via a URL which, in normal circumstances, would be expected to take you to the home page of this company, but the content in question is just some small bit of HTML that my various web browsers refuse to render for some reason. The same problem seems to also and likewise afflicts what should be the home page for dunsnet.com. And the same again also for the web site associated with tthe domain name mentioned in the WHOIS record for AS54163, ahostinginc.com. (Remember that this ASN is currently routing all of the 159.174.0.0/16 block.) In this last case however the content provides some clues as to an apparently related business known as aseohosting.com, where the "SEO" part apparently stands for "Search Engine Optimization". https://pastebin.com/raw/PnpgnA2A A simple Google search for Mr. Erkan Ozdogan turns up little of interest, however a similar search in the case of Mr. Adnan Canturk turns up multiple bits of his social media footprint: https://www.linkedin.com/in/adnan-canturk-24a66633 https://twitter.com/adnan_canturk The latter page provides us with a link to Mr. Canturk's personal web site, adnancanturk.com, but this also appears to have a dysfunctional home page. Nontheless, the text content that can be fetched from that URL further confirms Mr. Canturk's apparent connection to a business named "Aseohosting": https://pastebin.com/raw/NTW9nH6G Despite all of these dysfunctional web sites and home pages, the web site and the home page of aseohosting.com appears to be very much alive and well at present: https://www.aseohosting.com/ It is my hope that I will not have to go into too much detail in order to explain to the audience here why the use of large numbers of unique IPv4 addresses might be viewed by some as an integral part of any one of the net's myriad and almost entirely useless "SEO" schemes whose intent is the fundamental hoodwinking of search engines, such as Google, and their algorithms. The ultimate goal of these schemes, of course, is to snooker the search engines into displaying certain results above others. The bottom line is that it would appear that in this case, in the year 2011, Mr. Ozdogan and Mr. Canturk found themlseves a convenient and zero cost way of acquiring a sizable supply of IPv4 addreses, and that at the present time these valuable legacy IPv4 addrdesses are being employed (wasted?) on one big and undoubtedly fruitless search engine optimization scheme. To say that this is not the highest, best or most efficient use of the increasingly scarce supply of IPv4 addresses would, I'm sure, be a serious understatement. (To paraphrase my mother's early admonitions to me at dinner time "There are children starving in Asia would would like to have those IP addresses!") I must note that before posting this message I have made what I believe to be reasonable efforts to contact both Mr. Ozdogan and Mr. Canturk via every email address I could find for them, offering them the opportunity to respond to the preceeding facts and my interpretation of them, while promising those gentlemen that I would post their responses, whatever they might be. No response was received to this offer by press time. I also emailed John Curran, CEO of ARIN, prior to posting this message, and also offered him an opportunity to provide me with a response. This is his response: "ARIN does not comment on specific registry changes (as number resource change requests are made in confidence), but we do take matters of potential number resource fraud quite seriously. As you have chosen not to report this case of potential fraud, ARIN will not be investigating at this time, but we would welcome a fraud report if you believe that there is a need for investigation." -- John Curran, CEO, ARIN In closing I would just like to offer my personal observation that over time it appears to me that ARIN has been repeatedly victimized by this exact form of rather transparent fraud based on corporate identity theft. Instances of this date back to 2008, and now appear to have occurred as recently as last year. (More about that later.) I find this fact more than a little troubling, not least because of the apparent correlation between the specific IPv4 blocks that have been purloined in this manner and the congregation of Internet bad actors... spammers, hackers, and all manner of other Internet hooligans and miscreants... in and around the relevant stolen blocks. I understand that ARIN has neither the mandate to perform exhaustive investigations of all requests it receives, nor the kind of unlimited resources that might be required in order to do exhaustive investigations on a routine basis. That having been said however, in this and other such instances, the fradulent nature of the requests has been really rather obvious and transparent, requiring only the most modest amount of effort to note one or more of the glaring red flags and thus the need for further inquiry. I feel compelled to also note that ARIN's responses to cases such as this (e.g. the case of the 143.95.0.0/16 block) or, more accurately, the general lack of such responses may ultimately prove to be problematic, not just for ARIN but for the United States Department of Justice, e.g. in its current prosecution of federal criminal case 3:18-CR-04683-GPC: https://krebsonsecurity.com/2019/09/feds-allege-adconion-employees-hijacked… I am not immediately persuaded that a case could not be made, by the defense in that case, for selective prosecution. To an outsider such as myself, it seems that it might be difficult to defend and justify a decision to criminally prosecute one case in which ARIN was allegedly defrauded, apparently by persons of less-than-impressive means, while electing to -not- prosecute a half-billion dollar corporation, such as EIGI, against which the weight of the evidence may perhaps be equally compelling. This is the kind of slippery slope that one begins to traverse when one is guided by convenience or pragmatics, rather than by even-handed principal. Regards, rfg P.S. I have previously been in contact with a representative of Orange S.A., formerly France Telecom, and have requested that he arrange for his company to take back control of what would appear to be their partial ownership of the 159.174.0.0/16 block. To the best of my knowledge, no action has been taken by the company in this direction. To date I have to date been utterly unable to make contact with any representative of Deutsche Telekom in order to likewise encourage that company to reassert its apparently rightful claims to the 159.174.0.0/16 block. I would thus appreciate any referrals to any actual natural persons in that company with whom I might be able to discuss this matter. (I have a standing policy of never attempting to converse with unaccountable anonymized role accounts. Based on past experience, this is without exception an utter waste of my time.)

6 6

Re: Starting to Drop Invalids for Customers
by Jakob Heitz (jheitz) 03 Feb '20

03 Feb '20

Mark, Thanks for bringing this up again. I remember this from nearly 3 years ago when Randy brought it up. A bug was filed, but it disappeared in the woodwork. I have now given it the high priority tag that it should have had initially. Sorry about the mess up. In the meantime, you may be able to signal the validation state in iBGP once it is validated at the network edge. For an iBGP neighbor, use a configuration like this: neighbor 192.0.2.1 announce rpki state Regards, Jakob. Date: Sat, 11 Jan 2020 23:12:27 +0200 From: Mark Tinka <mark.tinka(a)seacom.mu> On 10/Jan/20 16:15, Lukas Tribus wrote: > Thanks for sharing all this. Regarding those 2 platforms specifically, > what release are you using here that does not blow up? On the ASR920, we are on 16(11)01a. On the ME3600X, we are on 15.6(2)SP6. > IIRC you had > some RPKI related crash bugs at some point in time? Yes, that was the first time we were deploying RPKI in 2014 and the code back then crashed the ME3600X. No such problem this time around. > - there is no ROA, so prefixes are supposed to be UNKNOWN on all nodes > - but IOS-XE prefers VALID over UNKNOWN (changing best path selection) > - iBGP is *always* VALID (even if it's really UNKNOWN), eBGP is > showing UNKNOWN, so iBGP is preferred over eBGP which breaks a lot of > assumptions and "hot potato" concepts (possible temporary routing > loops, other than of course different egress behavior) So your timing on this is ominous. In the last day or so, we had an issue with a customer on one of our ASR1006 edge routers that fell victim to this IOS XE stupidity. An alternate path toward them learned from a peer was sent back to the edge router they are connected to, which chose it over the local one because, well, it was an iBGP route. We didn't notice this issue with this customer since enabling ROV on this box weeks ago, which means the alternate route became available in the last 2 - 3 days, e.g., perhaps they turned up an alternative provider, or changed their routing toward them for us to see another path. Since this IOS XE stupidity is not configurable, what we've decided to do is disable ROV on all ASR1006 boxes for now. This is not a big issue for us. We've only got 2 customers using them as these boxes only carry non-Ethernet customers. While this should be an issue for our ASR920 and ME3600X routers also, it isn't because we run BGP-SD on those, i.e., even if the RIB will have all iBGP routes marked as Valid, they won't be installed in FIB, whereas the eBGP routes learned locally from the customer will. Having to create a ROA to solve this, while feasible, is inappropriate for a solution, especially when Juniper do it correctly. Randy and I complained to Cisco about this years back, and AFAIK, it was only fixed in IOS XR. That this is still going on in 2020 is silly, especially when it's clear that they are in violation of the RFC. > Apparently there is an IOS feature "Announce RPKI Validation State to > Neighbors" to transmit the *real* RPKI state in iBGP (so as opposed to > defaulting to VALID for all iBGP neighbors), I'm not sure if that > fixes this problem or not. It doesn't really address the root cause > (which is: unwanted and not configurable interference with the best > path selection algorithm) - but at it can at least hide it's symptoms. I've not tried communicating RPKI state between routers via BGP communities. One of the reasons I like RPKI is because it is a feature that works on each router independent of another. Each router has a discrete RTR session to a validator, and can make its own RPKI decisions without any regard for the rest of the network. And yet all routers in the network can do this and equally have a converged RPKI state, without ever speaking to one another. So the idea of having routers co-ordinate RPKI information through communities is one I am not so keen on, if I'm honest. Not only do you need to worry about inter-op issues between vendors, there is potential for problems when code changes over time. I'd rather not deal with that, especially since what Cisco are doing with IOS XE is simply a broken implementation. That said, if there is anyone out there who has done this and sees it as a solution to the problem, I'm sure this list would like to hear about it. > RPKI implementations should not touch best path selection. Dropping > RPKI invalids is the real use-case here, and if someones wants to > loc-pref based on RPKI status we should allow it (even if it doesn't > make a lot of sense), but having the RPKI implementation intervene in > the best path selection without the possibility to disable it is ... > frustrating. Agreed. At least, if IOS XE had a knob that could "set rpki [valid|notfound|invalid]" this would somewhat help. But alas, they don't :-(. You can only match on existing RPKI state. You cannot manually set RPKI state in IOS XE routing policy. I mean, how dumb is that? It's pretty presumptuous of Cisco to automatically apply policy for you re: RPKI in IOS XE, but then show they can do it right in IOS XR. Unreal! > > How much do you rely on "hot potato" routing for peers/transit and > customers? How does that work for you with RPKI unkowns? As above, we've disabled RPKI on all ASR1006 edge routers. It affects only 2 of our customers, so not an issue. I'll go through a few bottles of wine and some music this weekend as I summon up the energy to write to Cisco again to fix this. If I don't, I'll just keep sending money Juniper's way. Simple, and simpler! Mark.

3 3

AS16509 contacts in peering?
by Siyuan Miao 01 Feb '20

01 Feb '20

Hello, Anyone has peering contacts in AS16509 other than peering#amazon(dot)com? We'd like to establish peering with additional locations to balance the AnyCast traffic but unfortunately got no response in the last 6 months. Also, they forgot to update PeeringDB records on PTT Metro SP. Thanks,

1 0

AFRINIC: The Saga Continues
by Ronald F. Guilmette 01 Feb '20

01 Feb '20

My apologies to all. Certain of the blocks mentioned in my prior posting here have already been reclaimed, and are currently being routed by appropriate parties. In particular, these ones: 152.108.0.0/16 155.237.0.0/16 165.4.0.0/16 165.5.0.0/16 Also, I somehow managed to miss mentioning a few blocks that were also quite clearly stolen as part of this extensive and elaborate scheme, specifically these ones: 160.116.0.0/16 163.198.0.0/16 164.88.0.0/16 196.15.96.0/18 A full list of all of the stolen AFRINIC blocks that are still of ongoing concern at the present moment, taking into account the above adjustments, is available here: https://pastebin.com/raw/71zNNriB Note that many of the blocks listed at the link above have already been "reclaimed" as far as the AFRINIC WHOIS records are concerned. But because routing remains almost entirely decoupled from RIR WHOIS data bases, much of this "reclaimed" space is still being routed as I write this. The only difference is that now the space is being routed as bogons, rather than as "legitimately" allocated space. A summary of all of the current routing for all of the stolen AFRINIC IPv4 address space that is still of concern, including routing for recently reclaimed address space that AFRINIC will eventually be returning to its free pool is provided below. This list is sorted by the number of constituent stolen /24 blocks being routed by each listed network, thus showing the most major offenders at the top. A few footnotes concerning specific ASNs in this list follow below the listing. I urge everyone on this mailing list to share this data as widely as possible in and among the global networking connunity. In all cases noted below, the networks in question are unambiguously routing IP blocks that were obtained, in the first instance, via thefts perpetrated by one or more AFRINIC insiders and then resold on the black market in secretive deals. In many and perhaps most cases listed below, the relevant networks appear to have been more than happy to accept some cash in exchange for their services, while not looking all that carefully at the purported (but fradulent) "LOA" documents they were handed. (Repeated use of blatantly fradulent documents has been one of the consistant features of this entire ongoing criminal enterprise.) All routing data is derived from current data published by RIPEstat. ====================================================================== 3719 0 ?? UNROUTED IP SPACE 629 132165 PK Connect Communication 512 18013 HK Asline Limited 504 19969 US Joe's Datacenter, LLC 500 62355 CO Network Dedicated SAS 423 202425 SC IP Volume inc 286 58895 PK Ebone Network (PVT.) Limited 250 136525 PK Wancom (Pvt) Ltd. 192 18530 US Isomedia, Inc. 186 9009 GB M247 Ltd 134 262287 BR Maxihost LTDA 132 204655 NL Novogara LTD 79 132116 IN Ani Network Pvt Ltd 75 136384 PK Optix Pakistan (Pvt.) Limited 68 132422 HK Hong Kong Business Telecom Limited 60 137443 HK Anchnet Asia Limited 48 63956 AU Colocation Australia Pty Ltd 26 132335 IN LeapSwitch Networks Pvt Ltd 21 131284 AF Etisalat Afghan 20 139043 PK WellNetworks (Private) Limited 19 43092 JP OSOA Corporation., LTD 17 36351 US SoftLayer Technologies Inc. 16 56611 NL REBA Communications BV 16 199267 IL Netstyle A. Ltd 16 23679 ID Media Antar Nusa PT. 14 137085 IN Nixi 10 63018 US Dedicated.com 9 136782 JP Pingtan Hotline Co., Limited 8 45671 AU Servers Australia Pty. Ltd 8 57717 NL FiberXpress BV 7 49335 RU LLC "Server v arendy" 7 134451 SG NewMedia Express Pte Ltd 6 49367 IT Seflow S.N.C. Di Marco Brame' & C. 6 26754 ?? {{unknown organization}} 5 198504 AE Star Satellite Communications Company - PJSC 5 198381 AE Star Satellite Communications Company - PJSC 4 38001 SG NewMedia Express Pte Ltd 4 263812 AR TL Group SRL ( IPXON Networks ) 4 30827 GB Extraordinary Managed Services Ltd 4 42831 GB UK Dedicated Servers Limited 4 37200 NG SimbaNET Nigeria Limited 4 133495 PK Vision telecom Private limited 4 198394 AE Star Satellite Communications Company - PJSC 2 44066 DE First Colo GmbH 2 198247 AE Star Satellite Communications Company - PJSC 2 133933 PK NetSat Private Limited 2 328096 UG truIT Uganda Limited 2 38713 PK Satcomm (Pvt.) Ltd. 2 31122 IE Digiweb ltd 2 46562 US Total Server Solutions L.L.C. 2 13737 US Riverfront Internet Systems LLC 2 11990 US Unlimited Net, LLC 2 20860 GB Iomart Cloud Services Limited 2 45382 KR Ehostict 2 17216 US Dc74 Llc 2 16637 ZA Mtn Sa 2 53999 CA Priority Colo Inc 1 23470 US ReliableSite.Net LLC 1 35074 NG Cobranet Limited 1 19832 ZA Link Data Group 1 43945 IL Netstyle A. Ltd 1 134917 IN Ragsaa Communication pvt. ltd. 1 203833 DE First Colo GmbH ====================================================================== The actual current route announcements corresponding to all of the above are listed in the table given here, which is sorted by ASN: https://pastebin.com/raw/XQyJ8EK2 Footnotes: [1] AS62355 gives all indications of being a false front fradulent network, possibly one that was set up by one or more of the black market dealers involved in this case. There is no actual web site associated with its contact domain (networkdedicated.com) at present, the alleged contact phone number in the associated AS WHOIS record was non-orking when I tried it, and the street address given for this entity in Bogotá, Columbia, is one that Google maps cannot locate. Traceroutes to the one and only IPv4 block that is being routed by this AS and that is actually registed to the company itself (185.39.8.0/22) do not terminate in Columbia, South America, as one would expectm, based on the WHOIS, but rather such traceroutes dead- end somwhere on the network of core-backbone.com (Core-Backbone GmbH, Germany) in the general vicinity of Amsterdam, Netherlands. [2] The networks of AS202425 (IP volume, Inc. - Seychelles), AS204655 (Novogara, Ltd. - Netherlands), AS56611 (REBA Communications BV - Netherlands), and AS57717 (FiberXpress BV - Netherlands), are all believed by me to be onwed and controled by a certain pair of Dutch gentlemen who I have previously posted about. For more information on these characters, please google for "Ecatel" and/or "Quasi Networks". Both of those are, I believe, demonstratably the predecessors of what is now called "IP volume, Inc." [3] AS199267 (Netstyle A. Ltd. - Israel) and AS43945 (Netstyle A. Ltd. - Israel) belongs to one of the persons featured in Jan Vermeulen's detailed December 4th report on this whole AFRINIC caper, i.e. the particular fellow who has been going around passing out fradulent LOAs of such shockingly low quality that one wonders why he even bothers. [4] AS26754 was formerly an AFRINIC-assigned ASN which was assigned to the entirely fictitious business entity called "ITC'. That entity appears to have just been an imaginary concoction of Mr. Ernest Byaruhanga, formerly of AFRINIC, and now the target of an ongoing crimininal investigation in Africa, and/or other AFRINIC insiders who worked with or along side Mr. Byaruhanga to criminally strip assets from AFRINIC and its legacy block holders. The registration for this AS number has now been withdrawn by AFRINIC, thus rendering the ASN itself a bogon. [5] AS19832 ("Link Data Group") is yet another fiction that was manufactured out of -nearly- whole cloth, either by Mr. Byaruhanga and/or by other AFRINIC insiders who were working with him. It is not immediately clear why this ASN is still registered, let alone why is its route announcements are still being accepted or propagated anywhere.

5 5

CBS All acess/irdeto
by Michael Crapse 31 Jan '20

31 Jan '20

Our eyeball customers all of a sudden can no longer reach their CBS all access content. Inspection of the network connections now show a 403 error when trying to post to https://cbsi.live.ott.irdeto.com/widevine/getlicense code: 100214 message: "The request originated from ip address 196.53.97.0 which is not included in the JWT ips claim." I'm going to assume that they randomly started geolocating differently. Wonder if it's either CBS, or irdeto that can help us resolve our IP block 196.53.96.0/22 issues.

2 1