On Sat, 28 Sep 1996, Matthew Petach wrote:
I think your letter will raise the awareness of this kind of problem. Of course we all know it's possible, but it's not a problem that we've had to deal with on a malicious level.
? I do assume that there's no doubt the evil-isp is doing this maliciously?
This is the third time they've done this. The first two times we chalked up to ignorance and stupidity.
This time, though, we're not as willing to give them the benefit of the doubt.
I don't believe you. If you were as confident as you say you are that this is an evil ISP you would have just said:
*grin* Well, since this is the first time sending a report of something like this to NANOG, I didn't know there was a form I was supposed to fill out first. :-)
Evilnet Inc. is blackholing my routes. I've sent mail to techie@evilnet.inc, bigboss@evilnet.inc and chambermaid@evilnet.inc and nobody returns my mail. I phoned them at 1-888-555-2222 and left voicemail, I faxed them at 1-888-555-1111 and I don't get any response.
JVNC.net is blackholing my routes. We've called their NOC, their techsupport, and everyone listed in the whois listing.
In this way you accomplish the following:
1) clear identification of the problem, i.e. blackholed routes
2) clear identification of who seems to be causing the problem
3) clear identification of the contact means that you tried and the results or lack thereof obtained.
As a result, somebody who happens to know that Joe Bloe is the techie at EvilNet can call Joe at home and say, "Hey Joe, did you know that so-and-so doesn't like what you are doing and can't get a hold of you by email or telephone. Maybe you better fix this...". Or it could be Evilnet's upstream who contacts them. Or somebody could email you Evilnet's secret "human" NOC phone number, or whatever.
And if they want examples of the problems, here's a traceroute from Stanford University, where I happen to have an account, over to one of our customers. nyx.Stanford.EDU> traceroute pdm.xo.com traceroute to pdm.xo.com (205.158.193.246): 1-30 hops, 38 byte packets 1 ceras-gateway.Stanford.EDU (36.190.0.1) 2.69 ms 1.60 ms 1.59 ms 2 Core-gateway.Stanford.EDU (171.64.2.1) 3.16 ms 2.17 ms 2.4 ms 3 SUNet-Gateway.Stanford.EDU (171.64.1.34) 3.29 ms 2.62 ms 2.57 ms 4 su-pr1.bbnplanet.net (198.31.10.3) 2.19 ms 2.26 ms 2.50 ms 5 paloalto-mci.bbnplanet.net (131.119.0.202) 3.16 ms 3.46 ms 3.12 ms 6 borderx1-hssi2-0.SanFrancisco.mci.net (204.70.158.101) 115 ms 68.5 ms 10.0 ms 7 border3-fddi-0.SanFrancisco.mci.net (204.70.2.163) 4.78 ms 5.17 ms 6.55 ms 8 santa-clara.west.cix.net (149.20.64.1) 107 ms 205 ms 224 ms 9 jvnc-cix.west.cix.net (149.20.6.2) 86.2 ms (ttl=243!) 97.1 ms (ttl=243!) 90.5 ms (ttl=243!) 10 unclesam-ser1.jvnc.net (130.94.15.249) 86.5 ms (ttl=244!) 84.6 ms (ttl=244!) 95.1 ms (ttl=244!) 11 liberty-ser3-2.jvnc.net (130.94.11.250) 160 ms 90.3 ms 146 ms 12 bcn-hq.jvnc.net (130.94.40.253) 90.7 ms 135 ms 96.0 ms 13 204.70.179.110 (204.70.179.110) 85.0 ms (ttl=20!) 85.7 ms (ttl=20!) 86.8 ms (ttl=20!) 14 jc-bcn.jvnc.net (130.94.52.2) 93.4 ms (ttl=19!) 93.6 ms (ttl=19!) 96.6 ms (ttl=19!) 15 dialogic-gateway.jvnc.net (130.94.56.50) 108 ms (ttl=18!) 105 ms (ttl=18!) 96.5 ms (ttl=18!) 16 146.152.224.250 (146.152.224.250) 103 ms (ttl=17!) 113 ms (ttl=17!) 106 ms (ttl=17!) 17 146.152.241.249 (146.152.241.249) 175 ms (ttl=16!) 185 ms (ttl=16!) 181 ms (ttl=16!) 18 146.152.160.1 (146.152.160.1) 177 ms (ttl=49!) 195 ms (ttl=49!) 183 ms (ttl=49!) 19 146.152.160.249 (146.152.160.249) 174 ms (ttl=16!) 175 ms (ttl=16!) 179 ms (ttl=16!) 20 146.152.160.1 (146.152.160.1) 179 ms (ttl=49!) 176 ms (ttl=49!) 181 ms (ttl=49!) 21 146.152.160.249 (146.152.160.249) 177 ms (ttl=16!) 177 ms (ttl=16!) 184 ms (ttl=16!) 22 146.152.160.1 (146.152.160.1) 180 ms (ttl=49!) 180 ms (ttl=49!) 193 ms (ttl=49!) 23 146.152.160.249 (146.152.160.249) 188 ms (ttl=16!) 192 ms (ttl=16!) 199 ms (ttl=16!) 24 146.152.160.1 (146.152.160.1) 180 ms (ttl=49!) 182 ms (ttl=49!) 192 ms (ttl=49!) 25 146.152.160.249 (146.152.160.249) 190 ms (ttl=16!) 183 ms (ttl=16!) 197 ms (ttl=16!) 26 146.152.160.1 (146.152.160.1) 218 ms (ttl=49!) 189 ms (ttl=49!) 182 ms (ttl=49!) 27 146.152.160.249 (146.152.160.249) 186 ms (ttl=16!) 199 ms (ttl=16!) 186 ms (ttl=16!) 28 146.152.160.1 (146.152.160.1) 187 ms (ttl=49!) 188 ms (ttl=49!) 188 ms (ttl=49!) 29 146.152.160.249 (146.152.160.249) 190 ms (ttl=16!) 199 ms (ttl=16!) 213 ms (ttl=16!) 30 146.152.160.1 (146.152.160.1) 186 ms (ttl=49!) 189 ms (ttl=49!) 187 ms (ttl=49!) nyx.Stanford.EDU> This is the same traceroute AFTER we put in the more specific routes, to override their bogus announcement: nyx.Stanford.EDU> traceroute 205.158.193.82 traceroute to vn.com (205.158.193.82): 1-30 hops, 38 byte packets 1 ceras-gateway.Stanford.EDU (36.190.0.1) 2.13 ms 1.61 ms 2.13 ms 2 Core-gateway.Stanford.EDU (171.64.1.1) 2.74 ms 1.62 ms 1.82 ms 3 SUNet-Gateway.Stanford.EDU (171.64.1.34) 2.80 ms 2.23 ms 2.13 ms 4 su-pr1.bbnplanet.net (198.31.10.3) 6.47 ms 2.16 ms 1.79 ms 5 paloalto-br2.bbnplanet.net (4.0.1.90) 3.54 ms 3.14 ms 2.64 ms 6 sanjose1-br3.bbnplanet.net (4.0.1.14) 6.65 ms 3.19 ms 4.1 ms 7 mae-west.agis.net (198.32.136.21) 299 ms 21.8 ms 7.45 ms 8 santaclara.santanap.agis.net (206.62.13.249) 9.60 ms (ttl=246!) 7.55 ms (ttl=246!) 9.30 ms (ttl=246!) 9 internex.santanap.agis.net (206.62.13.18) 6.81 ms (ttl=249!) 7.32 ms (ttl=249!) 12.0 ms (ttl=249!) 10 area-1-rtr-fddi.InterNex.Net (205.158.0.2) 9.31 ms (ttl=248!) 13.8 ms (ttl=248!) 13.0 ms (ttl=248!) 11 milpitas01-S0.POP.InterNex.Net (205.158.2.26) 208 ms (ttl=247!) 38.9 ms (ttl=247!) 87.3 ms (ttl=247!) 12 Milpitas01-Max1.POP.InterNex.Net (205.158.3.68) 64.1 ms (ttl=55!) 44.8 ms (ttl=55!) 24.2 ms (ttl=55!) 13 Milpitas01-rtr.POP.InterNex.Net (205.158.3.65) 20.9 ms (ttl=247!) 18.0 ms (ttl=247!) 35.5 ms (ttl=247!) 14 Milpitas01-Max1.POP.InterNex.Net (205.158.3.68) 28.5 ms (ttl=55!) 23.0 ms (ttl=55!) 42.0 ms (ttl=55!) [ ... ] nyx.Stanford.EDU> (It's a dialup customer, so it makes it to the Max, and then bounces back and forth to the cisco and back to the max a bunch of times, but that's where it SHOULD be, within OUR network)
We did this last time, in complaining to MCI, their upstream provider, and MCI responded in record time, putting in a temporary filter for those blocks in less than 36 hours.
That helped for about 30 seconds, before we found that they then announced the same blocks through a second connection which hadn't shown up as a path previously when we did a 'show ip bgp 205.158.193.0 255.255.255.0 l'
Trying to solve a social problem with technology often results in this kind of thing.
It's a bit of an uphill road for an old network engineer to shift from technology solutions to social engineering solutions, but I think I'll figure out the requirements soon enough, given incentives like this.
I miss the older, more democratic days of the net, but it seems the overall level of knowledge and skill is dropping, forcing more and more levels of checks and balances to prevent abuse either through stupidity and ignorance, or malicious intent.
I think you are jumping to conclusions here by assuming it is due to stupidity, ignorance or malicious intent. I strongly suspect that it is due to lack of information and work overload. Lack of information is subtly but significantly different from stupidity and ignorance and you yourself are contributing to Evilnet's lack of information by withholding important information about the problem.
Shine the light of day on the problem and it will soon clear up. Throw all the relevant information into the "public" NANOG mailing list pool and numerous avenues for action will open up.
Hm. Well, I can list the whois entry for jvnc.net to list the phone numbers of the contact people. Is there a master list of AS #'s with ROUTING contacts, rather than the fuzzy admin type contacts that get listed in whois? Right about now, I'm still searching for information myself, but I'll put as much forward as I can.
Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
Matt Petach still learning all the nuances of this social troubleshooting...