- NANOG - lists.nanog.org

Re: spam whore, norcal-systems.net
by Dean Anderson 03 Feb '99

03 Feb '99

You have the right to monitor, but you weren't monitoring in the first place. And thats why Ravi's monitoring and publishing is legal? You sound like the manager on Dilbert. I'll tell you what. I'll do my part. I'll assume I was a recipient of one of Norcals spams (in fact I think I was), and thus being one of the parties whose electronic privacy was violated I can complain about Verio's unauthorized monitoring. I didn't give Verio permission. Norcal didn't give Verio permission. I'll forward the post to norcal and verio's agents, and the US attorney. Thanks. Now maybe we can get a court case on record. --Dean At 11:17 AM 2/2/1999 -0500, Christopher Neill wrote: >Thanx Dean.. actually, we do have the right to monitor traffic on our network, which we werent doing in the first place. What we had was an extended access list that matched tcp port 25 outbound from their /23, and logged that. Since they were using us as a transit provider for their dubious activities we are well withing our rights per our AUP (http://www.qual.net/support/aup.html) But its too late for you to take back your post. Think first. > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

4 3

Cisco >224.0/3 problems..
by James Rishaw 03 Feb '99

03 Feb '99

Hello all, Ran into a problem, thought maybe someone else has run into this and knows of a "fix", if this is intentional or what not. It seems that Cisco IOS has a problem dealing with addresses above 224.0.0.0/3. This came up in an e-mail with Paul Vixie about MAPS RBL, where I asked him why 224+ wasn't filtered. The reply was: IOS ignores it. GateD likes it, IOS doesn't. I'm finding that IOS isn't propagating routes, etc., (nor will it even seem to *recognize*) address space above 224. To wit: As a /3: bordercore1.chi(config)#ip route 224.0.0.0 224.0.0.0 Null0 %Invalid destination prefix /8, close to the end of address space: bordercore1.chi(config)#ip route 252.0.0.0 255.0.0.0 null0 %Invalid destination prefix As a /24: bordercore1.chi(config)#ip route 225.0.0.0 255.255.255.0 Null0 %Invalid destination prefix bordercore1.chi(config)#ip route 230.0.0.0 255.255.255.0 Null0 %Invalid destination prefix It's not Null0: bordercore1.chi(config)#ip route 234.128.230.123 255.255.255.255 h9/0 %Invalid destination prefix bordercore1.chi(config)#ip route 241.102.34.93 255.255.255.255 atm4/0 %Invalid destination prefix I know this is all "multicast" space, but considering classless routing and CIDR, shouldn't this space be usable and able to be manipulated ? -jamie -- jamie rishaw (efnet:gavroche) @ AIS / Exodus "I want peace on earth and goodwill towards men." "We are the United States Government. We don't do that sort of thing." --sneakers

2 1

trent's talk on the MAX
by Brett_Watson＠enron.net 03 Feb '99

03 Feb '99

someone might mention to trent (i'm watching at home) that the very exclusion tactics the "big guys" use to decide not to come to an exchange or not peer with someone is precisely what coop.net did when they decided not to let the "little guys" come to the MAX by saying "they're high maintainance". pot, kettle, black. -brett

2 1

SF Bay Area LEC discussion list?
by Jim Browne 03 Feb '99

03 Feb '99

I'm trying to gauge interest among San Francisco Bay Area operators (ISPs and knowledgeable corporate customers) with respect to starting a mailing list or forum dedicated to the notification of LEC operational issues specific to the Bay Area. I'm willing to run a list with a strict AUP. Such a list would allow customers of PacBell, ICG, TCG, Brooks, MFS, etc. to communicate outages such as the current DS0 shredding between Brooks and PacBell at SJ SpacePark. I'm interested in an emphasis on the tandems and PRI (dialup) related problems, but I'm sure there would be ample room for notifications regarding fiber cuts, DACS failures, and similar issues. If you are interested drop me a line. If sufficient interest arises, I'll make it a full-blown list. Jim Browne jbrowne(a)jbrowne.com "I wish journalism would return to its glory days, when principled incorruptible men like William Randolph Hearst and Joseph Pulitzer were in charge."- Vanessa Jackson, Piano Teacher, www.theonion.com

4 7

netscan.org being smurfed?
by Dalvenjah FoxFire 03 Feb '99

03 Feb '99

So it had to happen. http://netscan.org - the site listing all the current broadcast relays usable in smurf attacks - currently appears to be getting smurfed. traceroute to netscan.org (216.32.4.105), 30 hops max, 40 byte packets [...] 6 mae-west-ames.exodus.net (198.32.136.113) 18 ms 18 ms 20 ms 7 scca-02-h4-1-0.core.exodus.net (209.1.10.165) 18 ms 21 ms 19 ms 8 bbr02-p0-0.sntc01.exodus.net (209.1.169.49) 34 ms 34 ms * 9 * bbr01-p5-0.sntc03.exodus.net (209.185.249.142) 29 ms 33 ms 10 dcr01-p00000.sttl01.exodus.net (209.185.9.186) 66 ms 69 ms 66 ms 11 209.67.64.21 (209.67.64.21) 100 ms 108 ms * 12 * * * % ping -s netscan.org PING netscan.org: 56 data bytes ^C ----netscan.org PING Statistics---- 2 packets transmitted, 0 packets received, 100% packet loss % ping -s 209.67.64.21 PING 209.67.64.21: 56 data bytes 64 bytes from 209.67.64.21: icmp_seq=3. time=491. ms 64 bytes from 209.67.64.21: icmp_seq=7. time=89. ms ^C ----209.67.64.21 PING Statistics---- 9 packets transmitted, 2 packets received, 77% packet loss round-trip (ms) min/avg/max = 89/290/491 % ping -s 209.185.9.186 PING 209.185.9.186: 56 data bytes 64 bytes from dcr01-p00000.sttl01.exodus.net (209.185.9.186): icmp_seq=0. time=167. ms 64 bytes from dcr01-p00000.sttl01.exodus.net (209.185.9.186): icmp_seq=1. time=68. ms ^C ----209.185.9.186 PING Statistics---- 2 packets transmitted, 2 packets received, 0% packet loss round-trip (ms) min/avg/max = 68/117/167 Since I can't afford a lawyer to actually go after these negligents who can't seem to figure out that security is a part of being on the internet, I'm going to post a small rant here, again. Folks, it's not that hard to go to netscan.org (when it's not being smurfed), enter your subnets, and look to see if they give broadcasts. Heck, you could even automate it with a simple perl script. Give the task to one of your noc operators or something. Check your subnets, and your customers' subnets. And for those big ISPs out there who are getting targetted by smurf attacks, how about making your lawyers earn their keep and filing suit against the intermediaries for such things as gross negligence, anticompetitive practices, etc. etc. (note: I am not a lawyer). Have them get creative; I'm sure they're bored just sitting around poring over contracts all day. Talk to your managers. Make it a priority. But GET IT FIXED. I also advise you to fix the problem now, while the targets are still everyday users, and not 2 years from now, when Joe Achmed Terrorist discovers how easy it is to take down the pentagon from a UUnet dialup or a cable modem. Then, the FBI/CIA/military will come and fix it for you. (After they fix their own networks, of course }:P ). -dalvenjah P.S. Why am I sending this here? Because despite the fact that everyone on this list is in theory clueful, all the networks on netscan.org are customers of one of the big backbones or another, most of whom seem to have at least a minor presence on this list. If you have friends or contacts at backbones or ISPs who don't have a presence on nanog, forward away. If they are your customers, FIX THEM. You cannot get by with "they are responsible for their own networks" forever. Someone has to take responsibility. You should, before someone passes a law to force it upon you. -- Dalvenjah FoxFire (aka Sven Nielsen) DOS computers are by far the most popular Founder, the DALnet IRC Network worldwide. Macintosh fans, on the other hand, may note that cockroaches are far e-mail: dalvenjah(a)dal.net more numerous than humans, and that WWW: http://www.dal.net/~dalvenjah/ numbers alone do not denote a higher whois: SN90 life form.

1 0

Re: BGP Metrics
by Rusty Zickefoose 02 Feb '99

02 Feb '99

-----BEGIN PGP SIGNED MESSAGE----- My apologies, my question was apparently unclear. In the common situation where a downstream is allocated a sub-net from an upstream's super-block, and that downstream wishes to announce that sub-net to its neighbors, be those neighbors upstream, peer, or downstream of itself, or of the allocating upstream, the BGP algorithm does not appear to be equipped to handle the routing decision in an optimal manner. Thus far, I've encounter three methods of dealing with this situation. 1. Ignore routing aggregation - Everybody announces the sub-net. This works, but runs counter to a long standing goal of the community - reducing the size of the routing table. 2. Ignore the route announcement (netmask length) may work in some situations, but proves the point. 3. Local announcement only May be the result of 2 above, but again - proves the point. My question is, would the creation of a "multi-homed" flag in the BGP protocol be worth while discussing? I see this flag causing the algorithm to drop through the netmask test, and pick up at the metrics decision. Before persuing the question with the protocol folks, I thought I'd try to determine if there is enough interest in the capability to make it worth while. > > > > Hi all, > > I've occasionally noticed a requirement to disregard mask when > > determining preferred route in the BGP algorithm. Specifically, when > > a multi-homed customer wishes to announce both his delegated networks > > through both connections. The goal is to achieve true multi-homing, > > with out requiring the customer to get independent address space. Thus > > far, I've used various "miserable hacks". Has anyone else perceived a > > similar requirement? if so, has anything being done to get such a flag > > added? > > > > Or am I just missing the obvious? > > - -- Rusty Zickefoose | The most exciting phrase to hear in science, rusty(a)cw.net | the one that heralds new discoveries, is not | "Eureka!", but "That's funny ..." | -- Isaac Asimov -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Public key may be found at http://pgpkeys.mit.edu:11371 iQCVAgUBNrYZNe4+ch/bGDylAQEWggP/cmvcOAg5gQd1oETTMBZu/j00RgQ2v1/M dmDayiIhZpVcNEiDnkoZlPh875Lw3Czo+8JlFXooHeznXyBt8YdZq1aXs4Xa62O5 jOrrh1gHPpiOxIT5Qi4356Nx77PHbGGjPD/LtWXU/oZWH6rsQhl1DWZSvBZyQdnd lpOb3PV5ths= =zw4l -----END PGP SIGNATURE-----

2 1

Re: spam whore, norcal-systems.net
by Dean Anderson 02 Feb '99

02 Feb '99

Nanog is not a proper forum for spam discussion or spam announcements. A bunch of us on all sides of the issue agreed on this. Use spam-l or one of the other lists. In response, I get my one shot: (thanks) This kind of monitoring is probably a direct violation of 18 USC 2511, as is a public announcement of the monitoring results. Indeed, at present, I'd say it appears to be the best example of an unauthorized 3rd party violation I've seen so far. (most [all previous] people don't admit details, but we know some do it). Unless of course you have authorization from norcal or all the recipients of those 2 million packets to monitor. Since norcal isn't your customer, I don't suppose you have any paper showing they gave you permission to collect and publish information about their traffic. Its too late to take back your post. Think first. --Dean At 05:15 PM 2/1/1999 -0500, you wrote: >Just a heads up- > >Down stream customer and end-user spammer norcal-systems.net via >layer9.net started spamming yesterday afternoon. At first I was >going to dismiss this and wait till Monday, but the complaints >came in at a constant and fast pace. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

7 7

How slow can the internet/it's servers be.
by Leo Bicknell 02 Feb '99

02 Feb '99

NOTE: The following is not a rant, but is purely for humor value. In a world record for slowness of something, I got confirmation today that my PGP key had been added to the InterNIC's key ring. Thinking it had been a while since I submitted the request, I went back and looked at my E-mail. I submitted the add request on October 17, 1998. So, never fear, ye you think your request has been black holed by the InterNIC machine. You too will get your request back, maybe not today, maybe not tomorrow, but some day in the far, far, far distant future. As a network and server admin I _really_ want to know how you cause something to get held up for three months. I've made some major configuration blunders and the best I've been able to do is a couple of days. They have some tallented people over there. -- Leo Bicknell - bicknell(a)ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

2 1

Pacbell NOC
by Jeffrey Haas 02 Feb '99

02 Feb '99

This is a general request for Pacbell Internet to add themselves to http://puck.nether.net/netops/nocs.html Reporting security incidents to the "policy" department because people at the general number don't know who to talk to is a bit silly. (Unless, of course, that is the correct address.) -- Jeffrey Haas "Denial of Spamming is not a crime." elezar(a)pfrc.org -- Russell Nelson <nelson(a)crynwr.com>

2 1

Re: recent update from ARIN
by Phil Howard 02 Feb '99

02 Feb '99

> This reminds me of something else I recently wondered though. According to > the ARIN rules that allow an ISP to qualify for a /19 that they have 18 > months to grow into, if the ISP fails to do so, the top half of that /19 can > be revoked. What means can/does ARIN use to prevent such an ISP from > continuing to announce the /19 rather than just a /20? Does/can ARIN > pressure the ISP's upstreams to filter the /19? Just double the size of your current announcement and see what happens. It might be considered a DoS incident. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* phil at intur.net * --

1 0