- Test - lists.nanog.org

AS37135, AS6560, AS32714, AS14029 - Squatted or not? You be the judge.
by Ronald F. Guilmette 11 Nov '16

11 Nov '16

At least one person has now asserted to me in private email that my suggestion that AS30186 was being squatted on was in fact accurate. Thus, I now feel confident enough to provide here the rest of the story which goes along with that. In a nutshell, AS30186 and also two other ASNs, together appear to all be parts of a single large multi-ASN squat. In addition to what appears to be a squat on AS30186 (the former Ross Technology Inc. of Austin, Texas, which even Wikipedia says has been dead for lo these past 18 years) it appears to me, based on the evidence, that the exact same large scale spamming company is, at present, also usurping and squatting on two additional AFRINIC ASNs, namely AS37135 and AS6560. I provide here listings of the current forward resolutions of a sizable number of snowshoe spammer nonsense domain names (more than 1,400 in total) which are currently associated with various portion of several apparently illicitly appropriated AFRINIC /16 blocks: AS37135: http://pastebin.com/raw/PkBagrpJ AS6560 http://pastebin.com/raw/zg9W2agN The affected, and apparently long-orphaned AFRINIC IPv4 blocks involved are as follows. Note that these have each have their own AFRINIC block registration records which indicate that they belong to, among others, a chemicals & power company (155.237.0.0/16), a manufacturer of stainless steel products (160.115.0.0/16), an international mining company (163.197.0.0/16), a manufacturer of fertilizers and nitrogen compounds (163.198.0.0/16), an agricultural chemicals company (164.155.0.0/16), the Directorate of Information Services for the South African government (165.25.0.0), a Seychelles Islands ISP (168.80.16.0/15), and a South African outsourcing and business services company (196.9.0.0/16). Despite these "official" IPv4 block registrations, based on the evidence as shown in the above Pastebin reports, I am forced to conclude that somehow, magically, all of these long-dormant African entities recently began hosting parts of a large scale snowshoe spamming operation, including even the Directorate of Information Services for the South African government, as well as the South African Post Office (196.10.0.0./16), both of which appear to be kindly lending a hand to these spammers also. Here is the list of affected AFRINIC-allocatded IPv4 blocks: 152.108.0.0/16 155.159.0.0/16 155.235.0.0/16 155.237.0.0/16 160.115.0.0/16 160.116.0.0/16 160.122.0.0/16 163.197.0.0/16 163.198.0.0/16 164.155.0.0/16 165.25.0.0/16 168.76.0.0/16 168.80.16.0/15 196.9.0.0/16 196.10.0.0./16 196.16.0.0/14 196.15.64.0/18 Note that AS37135 and AS6560, which I contend are themselves being squatted on, are currently announcing numerous discrete and discreet /20, /21, and /19 blocks out of the above large blocks, perhaps with a view to the future and to switching their announcements to other and different sub-blocks within these same containing blocks, e.g. when they have so throughly sullied the reputations of the blocks they are currently using so as to have caused those blocks to be universally blacklisted everywhere. In any case, here are the current announcements being made by AS37135 and AS6560, respectively. Note that the set of announcements from these ASNs has changed, and significantly, even just within the past 24 hours. What you are seeing here is just the routes being announced by these two suspicious ASNs as I write this. AS37135: 152.108.0.0/19 155.235.80.0/20 155.235.128.0/19 155.235.224.0/19 155.237.128.0/21 155.237.128.0/19 160.115.32.0/20 160.115.48.0/20 160.115.64.0/20 160.115.80.0/20 160.115.96.0/20 160.115.112.0/20 160.116.112.0/20 160.116.160.0/20 160.116.192.0/20 160.122.0.0/19 160.122.128.0/21 160.122.240.0/21 163.198.0.0/20 163.198.64.0/20 168.76.128.0/20 -- Free State Education Department (not routed earlier today) 196.9.32.0/20 196.9.128.0/20 AS6560: 155.159.128.0/20 155.237.64.0/20 155.237.208.0/20 155.237.224.0/20 155.237.240.0/20 163.197.112.0/20 163.197.144.0/20 163.197.176.0/20 163.197.208.0/20 163.197.240.0/20 163.198.16.0/20 163.198.80.0/20 163.198.96.0/20 163.198.144.0/20 163.198.192.0/20 163.198.224.0/20 164.155.0.0/20 164.155.64.0/20 164.155.128.0/20 164.155.192.0/20 165.25.0.0/20 165.25.32.0/20 165.25.64.0/20 165.25.96.0/20 165.25.128.0/20 165.25.160.0/20 165.25.192.0/20 165.25.224.0/20 168.80.16.0/20 168.80.48.0/20 168.80.80.0/20 168.81.16.0/20 168.81.64.0/20 168.81.176.0/20 168.81.224.0/20 196.9.0.0/20 196.9.16.0/20 196.15.64.0/20 196.15.96.0/20 As I was preparing this post, two furter and additional dodgy looking ASNs also came to my attention, and preliminary analysis suggests that these two additional AFRINIC ASNs, AS32714, and AS14029, together with all of the IP space they are announcing, may perhaps also be squatted on at the present time. Given below are the current announcements from these two additional ASNs. Note that AS32714 is currently announcing routes to some South African IP address blocks, as well as to certain German blocks registered to Daimler AG, and also a number of Chinese /18 blocks registered to the Chinese retailing giant Alibaba, Inc... two companies which I suspect do not really require outside help from South Africa in order to obtain routing to their own IP blocks. Interestingly also, the former Zimbabwean ASN AS14029 does not appear to be actually registered to anyone at all at the present time. This minor annoyance does not, apparently prevent it from announcing a number of rather entirely dubious routes via its lone BGP peer AS260. AS32714: 47.93.0.0/18 47.93.64.0/18 47.93.128.0/18 47.93.192.0/18 53.122.1.0/24 53.122.2.0/24 165.10.0.0/16 196.10.64.0/19 AS14029: 41.77.240.0/22 155.159.254.0/24 155.159.255.0/24 160.122.70.0/24 160.122.71.0/24 168.81.254.0/24 168.81.255.0/24 196.10.61.0/24 196.10.62.0/24 196.10.63.0/24 203.212.160.0/20 I will be looking in more depth into AS32714 and AS14029 shortly, but for now I just wanted to make people aware of these additional two rather curious ASNs and the routes they are currently announcing. On a final note, it has not escaped my notice that all three of the ASNs AS37135, AS6560, and AS14029 appear to have only a single common BGP peer, that being AS260, Xconnect24 Inc. I suspect that this is not entirely a matter of coincidence. I have attempted to make contact via email with Xconnect24, but they have not replied to my polite inquiry. For its part, AS32714 also has but a single BGP peer, that being AS6939, Hurricane Electric, Inc. Regards, rfg

1 0

Seeking Google reverse DNS delegation contact
by Ronald F. Guilmette 11 Nov '16

11 Nov '16

Does anyone here happen to know who at Google I should be talking to if I want to ask a question about their reverse DNS services? I'd just like to ask someone there why anyone at Google thought that it would be a Good Idea for Google to provide reverse DNS services for the 204.8.136.0/21 IP address block, a block that appears to be chock-full to the brim of snowshoe spamming domains. http://pastebin.com/raw/VNwmgMHh http://pastebin.com/raw/Hk3SKGvp P.S. I gave up on the "evil" part some time ago. Now, I'm willing to settle for them just not being spammish.

1 0

AS30186 - Squatted or not? You be the judge.
by Ronald F. Guilmette 11 Nov '16

11 Nov '16

I kinda messed up the last time I posted something here about possible IP address block squatting, so I'm not going to make any definitive assertions regarding conclusion this time. I'm just going to lay out the facts and let all of you good folks decide for yourselves. AS30186 is registered to Ross Technology Inc. of Austin, Texas. Also registered to this same entity are the following IPv4 address blocks: 143.187.0.0/16 204.8.136.0/21 Wikipedia kindly provides us with information about this (former) company: https://en.wikipedia.org/wiki/Ross_Technology "Ross Technology, Inc. was a semiconductor design and manufacturing company, specializing in SPARC microprocessors. It was founded in Austin, Texas in August 1988 by Dr. Roger D. Ross,... ... Ross Technology closed down in 1998 and all its assets and patents became the property of Fujitsu Ltd." So, it would appear that we hve a zombie company, with its very own ASN and valuable /16 and /21 IPv4 address blocks to boot. According to the above history, these are all the rightful property of Fujitsu Ltd. Fujitsu Ltd. is not a small or insignificant company, and to the best of my knowledge it is not currently in any sort of financial straits or difficulties. It would thus seem somewhat implausible that Fujitsu, a big "household name" Japanese company would elect to either sell off or sub-lease out their ASN or either of their valuable Ross-related IPv4 address blocks to scumbag snowshoe spammers. Despite this fact however, abundant evidence I've collected recently indicates rather convincingly that both AS30186 and also, at least, the 204.8.136.0/21 address block are, at the present time, inhabited completely and only by a large scale snowshoe spamming operation. Current forward resilutions of numerous interrelated snowshoe spamming domains provide clear evidence of this: http://pastebin.com/raw/hEY1nxct AS30186 is announcing the following routes at the present moment: 143.187.0.0/24 143.187.1.0/24 143.187.2.0/24 143.187.3.0/24 143.187.4.0/22 143.187.8.0/21 143.187.16.0/20 143.187.32.0/19 143.187.64.0/18 143.187.128.0/24 143.187.129.0/24 143.187.130.0/24 143.187.131.0/24 143.187.132.0/22 143.187.136.0/21 143.187.144.0/20 143.187.160.0/19 143.187.192.0/20 143.187.208.0/20 143.187.224.0/20 143.187.240.0/21 143.187.248.0/21 204.8.136.0/21 I have today personally made a number of diligent efforts to contact any warm body at Fujutsu who both (a) speaks English and who also (b) knows hat an ASN is so that I could discuss this matter with some appropriate network administrator, but I was thwarted at every turn by Fujutsu's bureaucracy, despite having spoken by phone to individuals who I was told could help with this sort of thing, first in San Jose, then in Sunnyvale, and finally in the Phillipines. In the event that, as the evidence suggests, some party not associated with Fujutsu is currently making use of Fujutsu's /16 and /21 blocks, one would think that -someone- at the company might be eager to take back possession of these valuable assets, but apparently no one is. Data obtained by me from bgp.he.net suggests that AS30186 is currently connectedf to the Internet only by the following other ASNs: AS19257 - SUBRIGO CORPORATION AS3491 - PCCW Global I have already attempted to make contact via email with both of these companies regarding AS30186, but am still awating any reply from either. So far it is not looking good. In the meantime, I do encourage everyone to look over the content of the pastebin report whose URL is given above, and I encourage everyone to make up his or her own mind regarding the advisability of accepting traffic at the present time from any IPv4 space routed by AS30186. Regards, rfg P.S. The domains associated with the former Ross Technology, Inc. ASN and IPv4 address blocks appear to be part of a larger pattern upon which I will elaborate further in the near future.

1 0

OSPFv3 with IPSec between Cisco and Juniper gears
by Philippe Bonvin 10 Nov '16

10 Nov '16

Hello folks, Quick question about incompatibility between Cisco and Juniper gears. Without IPSec, OSPFv3 is working as expected. I'm trying to configure IPSec authentification of OSPFv3 between a Juniper SRX and a Cisco router but it seems that they didn't agree to a common key length. Can you confirm that this is a well-known problem or give me the right configuration that I should use ? The error message on the juniper: [edit security ipsec security-association ospfv3 manual direction bidirectional authentication key ascii-text] 'ascii-text "..."' Authentication key size must be 20 bytes On the cisco side: cisco(config-if)#ipv6 ospf authentication ipsec spi 256 sha1 0 ? Hex-string SHA-1 key (40 chars)? Here is an output of the config I'm using on the SRX side: ipsec { security-association ospfv3 { mode transport; manual { direction bidirectional { protocol ah; spi 256; authentication { algorithm hmac-sha1-96; key ascii-text "..."; ## SECRET-DATA } } } } } interface ge-0/0/0.0 { ipsec-sa ospfv3; } Thanks for your help, Philippe [EDSI-Tech Sarl]<http://www.edsi-tech.com> Philippe Bonvin, Directeur EDSI-Tech Sàrl<http://www.edsi-tech.com> EPFL Innovation Park, Batiment C, 1015 Lausanne, Suisse | Téléphone: +41 (0) 21 566 14 15, ext. 99 Savoie Technolac, 17 Avenue du Lac Léman, 73375 Le Bourget-du-Lac, France | Téléphone: +33 (0)4 86 15 44 78, ext. 99 Disclaimer: This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this information, be advised that you have received this email in error and that any usage, disclosure, distribution, copying of the information or any part of it in any form whatsoever is strictly prohibited. If you have received this email in error please notify the EDSI-Tech helpdesk by phone on +41 21 566 14 15 and then delete this e-mail.

2 2

Re: OSPF vs ISIS - Which do you prefer & why?
by Joel M Snyder 10 Nov '16

10 Nov '16

>> Vendor support for IS-IS is quite limited - many options for OSPF. >Depends on the vendor. I think you misunderstood his point: it's not the knobs, but the vendors. Generally, when you're trying to integrate random crap into an otherwise well-structured network, you'll find OSPF available, but very rarely IS-IS. I run into this a lot in the security appliance space, where you want your security appliances to either learn or advertise routes internally (VPN tunnel reachability is a big reason for this), but also in devices such as load balancers and other middlebox cruft that occasionally needs to participate in routing advertisement/subscription. Some vendors grab random open source routing protocol code that includes everything and dump it into their boxes, usually accessible via an entirely separate configuration interface; this can include IS-IS, but these implementations rarely actually work as they are usually "check list" implemented for a specific RFP or customer and never get widely tested. The ones who actually care about making it work almost always include RIP and OSPF, with a few shout-outs to BGP. IS-IS (and OSPF v3) rarely makes the cut. In a world where you are doing well-controlled Cisco/Juniper/etc networks with fairly homogeneous code bases, the engineers get to have this discussion. When you have to link in devices for which routing is not their primary reason to exist, your options narrow very quickly. It's not ideal; that's just the way it is. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms(a)Opus1.COM http://www.opus1.com/jms

6 5

JP Morgan contact
by Tom Storey 10 Nov '16

10 Nov '16

Would anyone from JP Morgan just so happen to be lurking on the list? If so, would you mind contacting me off-list regarding a reachability issue that some of my customers are experiencing with your website(s), specifically jpmpb.com. Thanks Tom

1 0

Re: OSPF vs ISIS - Which do you prefer & why?
by John Kristoff 10 Nov '16

10 Nov '16

On Wed, 9 Nov 2016 17:12:24 +0000 Michael Bullut <main(a)kipsang.com> wrote: > Although there isn't distinct 1:1 argument, it's good we discuss it > here and figure out why one prefer one over the other *(consider a > huge flat network)**.* What say you ladies and gentlemen? I'm not sure it is worthy of an argument. I think I've only ever heard of anyone migrating from one to the other. That was AOL presenting their conversion from OSPF to IS-IS at NANOG a number of years ago: <https://www.nanog.org/meetings/abstract?id=686> The article you refer to more or less covers some of the major differences, largely academic these days. They are close enough alike now that it is probably just best to use what you know or already have running. When I migrated a RIPv2 network to OSPF I don't remember if I consciously choose it over IS-IS for any particular reason or, more likely, just went with it because it seemed like the IETF-preferred way to go. That would have been a dumb reason and later I kind of wish I had used IS-IS, because of the security isolation at layer 2 and relatively modest changes to support IPv6. But I wouldn't go through the trouble of changing it now. There is no compelling reason. I've considered leaving IPv4 on OSPF and putting IPv6 on IS-IS, but I'm not sure it really matters. It might be nice to get the experience on the resume, but that might not be a good justification to the network staff and management for a production network. John

2 1

Re: OT: "Read Receipts"
by Larry Sheldon 10 Nov '16

10 Nov '16

I avoided the other off charter bait, but this is a red dot to me. On 11/6/2016 19:59, Patrick wrote: > Over at Language Hat, they are trying to establish the common > pronunciation of "read receipts" [1] > > To me, they've always just been "DSNs" or "MDNs", however, according to > rfc2298, their history goes back further. > > Of those who lived that history, and actually heard or said "read > receipts", did you pronounce "read" as "reed" or as "red"? I always pronounce them "More danged spam leaking thru the filters" but when I test-read (red) the question, R E A D came out "read (reed)". The burning questions we have to deal with these days, -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From Larry's Cox account.

1 0

OT: OpenSRS contact?
by Jessica Litwin 09 Nov '16

09 Nov '16

Apologies if this kind of thing isn't allowed but I'm at the end of my tether. If anyone who works at OpenSRS lurks here, can you contact me off-list? I have an issue support is unwilling or unable to fix and they don't seem too keen on escalating it. // jkl

1 0

dilemmas
by Randy Bush 08 Nov '16

08 Nov '16

the users' dilemma: do you buy a mac today, or wait six month hoping they will fix X (for your particular X)? the sysadmins' dilemma: do you install today's critical update or wait a day until the next one is out before you reboot 50 servers?

6 7