November 1999 - Test - lists.nanog.org

RE: ARIN whois
by Dean Anderson 27 Nov '99

27 Nov '99

Around 07:11 PM 11/25/1999 -0600, rumor has it that Edward S. Marshall said: >Show me one ISP/NSP out there who isn't running beta or alpha code >somewhere in their infrastructure. Never ran a x.0 version of IOS? Never >patched a piece of software with an "unsupported" patch to fix an issue >affecting service? Never developed such a patch yourself (or had a staff >member do so)? Beta/Final doesn't matter so much. It has to work. If it doesn't work, its not going to get deployed until it does work. We are looking into it. But it probably won't happen immediately, until we know it works, and doen't interfere with our services. While John Levine says it works already in exchange, and outlook, I haven't figured out (after only a little bit) how to configure it in Outlook, or Eudora. Or unix mail. So it probably will take some effort to deploy. >Incorrect. It's a customer training issue, and a little development time >on your part. If you can't use SMTP AUTH, don't. Use POP-before-SMTP. Whip >up a custom finger daemon to accept a username/password pair in the same >manner. Create a webpage for your customers to enter a username and >password on to authenticate themselves. Use a VPN. Use magic headers or >subject lines that your MTA catches and uses as identity verification. >Provide a web-based interface for your customer's email. Use UUCP. This is so foolish, I'm just about tired of explaining. Most of the people who continue asserting the above have been made aware that none of those schemes comply with standards. The SMTP AUTH RFC 2554 is standards track, but not standard. Anyway, as has been said numerous times before, ANY STANDARDS COMPLIANT MTA MUST BE ACCEPTABLE FOR USE BY A CUSTOMER. Pop before SMTP, or special web/vpn web apps don't cover the category of "any standards compliant mta". We know about them. Probably more than you. So please stop blathering about them. >Just because you're too lazy/ill-funded to develop a solution to a problem >YOU'VE created (by CHOOSING to offer that service to your customers), >don't expect us to feel sorry for you. Relay services have been around longer than spam. Certain antispammers created the problem by advertising our service as free to spammers to incite crimes. The antispammers created this problem on purpose because they are too few, too lazy, too unrealistic, too extreme, too politically inept, and too ill-funded to make spam illegal. So they have to resort to criminal acts [terrorism] to try to get the issue some attention. >Since when did NANOG become a forum for hosting issues? This will be my >only post to this thread on this list; take it to inet-access or >rbl-discuss, if you must. This has already been discussed on rbl-discuss, where the conclusion was that "soon we'll have a software solution for you." [implying that currently, we have to relay]. It has become an operational issue since legitimate operators are being attacked, and connectivity to the net is being affected. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

The Cidr Report
by Tony Bates 26 Nov '99

26 Nov '99

This is an auto-generated mail on Fri Nov 26 12:00:02 PST 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 26Nov99 0) General Status Table History ------------- Date Prefixes 071199 66095 081199 66195 091199 66908 101199 65842 111199 67577 241199 67406 251199 67521 261199 67449 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 219.91.160.0/22 from AS7742 *** Bogus 219.91.164.0/23 from AS7742 AS Summary ---------- Number of ASes in routing system: 6114 Number of ASes announcing only one prefix: 3245 (1783 cidr, 1462 classful) Largest number of cidr routes: 640 announced by AS701 Largest number of classful routes: 979 announced by AS701 1) Gains by aggregating at the origin AS level --- 26Nov99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 383 141 242 63.2% BCnet Backbone AS7046 386 257 129 33.4% UUNET-CUSTOMER AS1221 626 514 112 17.9% TELSTRA-AS AS2609 125 15 110 88.0% EUnet-TN AS9706 112 11 101 90.2% Pusan Metropolitan City Office of AS9269 126 27 99 78.6% Hong Kong CTI AS7657 264 168 96 36.4% The Internet Group Limited AS7545 146 60 86 58.9% TPG Internet Pty Ltd AS174 562 476 86 15.3% Performance Systems International AS7496 123 38 85 69.1% Power Up AS4293 226 142 84 37.2% Internal ASN for C&W AS577 265 185 80 30.2% Bell Canada Backbone AS3749 134 61 73 54.5% TECNET AS4200 181 111 70 38.7% AGIS (Apex Global Information Ser AS3602 309 245 64 20.7% Sprint Canada Inc. AS705 134 75 59 44.0% ALTERNET-AS AS4740 351 293 58 16.5% Ozemail Pty Ltd (ASN-OZEMAIL) AS816 251 194 57 22.7% UUNET Canada (ASN-UUNETCA-AS4) AS209 330 276 54 16.4% Qwest Communications AS684 92 46 46 50.0% Manitoba Regional Network Backbon AS701 979 936 43 4.4% Alternet AS1 522 480 42 8.0% GTE Internetworking AS549 213 172 41 19.2% ONet Backbone AS9304 56 16 40 71.4% Hutchcity AS6528 45 7 38 84.4% WORLD-LYNX AS2493 122 84 38 31.1% iSTAR Internet, Inc. AS4755 108 71 37 34.3% Videsh Sanchar Nigam Ltd. India AS6629 63 28 35 55.6% NOAA-AS AS1727 97 63 34 35.1% MRMS-WEST AS3737 99 66 33 33.3% PenTeleData Inc. (ASN-PTD) For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

RE: Re: Fwd: Bell Atlantic - Just a little congestion (corrected URL)
by Robert Cannon 26 Nov '99

26 Nov '99

I have not seen the NRIC report either. I am working on finding its status. Focus Group III of NRIC is the Focus Group working on this issue. Subcommittee 2 is looking at future considerations. This is the subcommittee that came up with the recommendation to have a trial period of ISP outage reporting. This Subcommittee is headed I believe by PJ Auduskevicz at ATT. According to FG III's calendar, http://www.atis.org/atis/nric/calsub2.htm, Subcommittee 2 met on 11/22. The NRSC met on 11/23. I am making an assumption that they were going to release the report on ISP outage reporting after these meetings. FG III's information is not on the NRIC page, it is on the ATIS page and can be found at http://www.atis.org/atis/nricgr3.htm Comments are due on the report in the beginning of December. If you are intersted in commenting on the report, let me know, and I will try to find out where to direct your comments. -Bob Cannon rcannon(a)fcc.gov ------Original Message------ From: Sean Donelan <sean(a)donelan.com> As Bob Cannon pointed out, the FCC is starting a "voluntary" project where ISPs would also file outage reports. So expect ISPs to start redefining things to avoid filing an outage report. I suspect that was also the reason why AT&T Wireless didn't initially file a report after Rochelle Park, although Bell Atlantic did. Wireless, cable, pager, satellite are treated seperately in the FCC regulations. The ISP reporting regulations were supposed to be posted on the FCC web site today, but I haven't found them yet. __________________________________________________ FREE Email for ALL! Sign up at http://www.mail.com

1 0

Re: Bell Atlantic FCC outage report available now
by David Lesher 26 Nov '99

26 Nov '99

> > It's called "cleared while testing" in the States... > Or NTF, No Trouble Found. Which bit them on the tail... Mother went bonkers for some manpower utilization analysis deal in her final decade+. So how it worked was you called in trouble, folks got dispatched to your end, they called the CO ("It's open looking back toward you") who first silently replaced the coils ('fuses' to laymen) and then said "looks good from here..." "Tested Good from the CO..." said the log. So the CO dodged the bullet and looked good on the weekly stats. But long term, the manpower study called for the CO's to be downsized; after all, they never had any trouble to work! A second aspect of this analysis was "paperwork does not count" -- there was little time for it in the 'budget' so it got skipped. This virtually destroyed the OPS [outside plant; i.e. cable pair] records; no one bothered to report bad pairs/ document new ones used. You just found a new pair and grabbed it. One day, there'd be no good pairs left. So STEAL one... "My ticket is closed on time, who cares about the NEW one it created.." Finally, Cable would getaclue and come work on the bad cable, but only after customers had all been victims of "paperwork matters less.." -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

Re: ARIN whois
by Dean Anderson 25 Nov '99

25 Nov '99

You missed the point. ORBS is the source of information for spammers. They are inciting attacks. I've got mail from Alan Brown inciting "script kiddies" to do just that. Our problems with unauthorized relays started after being listed by ORBS. They incite the attacks. They are responsible for attacks. We make sure the note this in our complaints the the FBI. They advertise the list of relays on a web page to incite attacks against those relays. They don't need to do this to block spam. --Dean Around 12:54 AM 11/25/1999 -0800, rumor has it that lists(a)die.net said: >> I do know that ORBS is uncommonly good at blocking relays. Much, much >> better than RBL. One admin I talked to recently told me about 8 of 10 >> relayed spams were identified by ORBS. Of course, is ORBS that good, or >> is ORBS actually the source of the relay attacks? > >This reasoning at least I can dispute. > >Due to my efforts to get a lot of my e-mail addresses in the hands of >spammers, I get 30,000 pieces of spam per month. Examining only those, and >doing my own relay testing on IPs found in them, I discover 1,000 new open >relays per month actively sending me spam that I've never seen before and >are not yet listed in ORBS, and submit them. I'm fairly certain that I'm >not the only one. I have no reason to believe that ORBS accepts submissions >from people who are actively portscanning, as there doesn't seem to be a >reason to. This method is effective enough. > >I've seen a lot of people giving ORBS shit for being too effective, and >listing relays within minutes or hours of someone spamming through them. >They even sometimes get confused as to the timing, and see the ORBS warning >message prior to noticing that their servers are lagged, and thus think ORBS >is the cause. > >But I fail to see how this thread is remotely on topic. Each site on the >net is fully capable of setting their own policy on which networks they want >to talk to. If you disagree with Dean's policy and feel he's adversely >affecting your network, don't let his servers connect to yours. He is >certainly free to do the reverse. Theres no particular need to reach global >consensus; if enough people refuse to transact with a party due to their >policies, they may wish to change them. > > Aaron Hopkins > Chief Technical Officer > Cyberverse, Inc. > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

mail relay thread
by Larry Snyder 25 Nov '99

25 Nov '99

:0: * ^Subject: RE: ARIN whois /dev/null If for no other reason than to fix the S+N/N ratio, _please_ move this. my .02 -ls-

1 0

Re: ARIN whois
by Dean Anderson 25 Nov '99

25 Nov '99

I'm surprised to see such poorly considered statements from JD. Unless SMTP AUTH (just released in sendmail 3 weeks ago) works in every client, and is support in MS Exchange, then we (that is we as an operations community) don't have the technology to practically authenticate it yet. I too can write an authenticated SSL client & server to transfer mail between two computers. But its not useful unless its widely deployed. Statements to the contrary are just foolishness in an operational context such as a real business. We are running a _BUSINESS_, not a research lab, with one server and one specially developed client. We don't run relays out of laziness. We went out of our way to enable them. We go out of our way to monitor them for unauthorized use. We would certainly prefer an authenticated mail system. We have to live with what is currently deployed. What annoys me about the pressure from the junior antispammer league is they go from "gee, you know you can close those relays" We respond "Yes, we know. We operate them on purpose for business reasons". At times, I've explained these business reasons in detail. The technical conclusion is then that we have to operate relays. They then jump to "Thats unacceptable. You MUST CLOSE THEM". We say "No. Absolutely not." They say "Well, in that case we're going to start committing crimes against your service, posting to alt.2600, inciting attacks, and wasting your time, bandwidth, and computer resources until you agree to close them." We say, thats extortion. We say that crimes against our service are crimes. We report them, and they will get eventually get punished, and we will work hard to get paid for the services rendered and the damages done by criminals. We don't tolerate this sort of behavior. Most companies don't. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

6 5

Network Visualization (Oops)
by Tim Salo 25 Nov '99

25 Nov '99

> Date: Wed, 24 Nov 1999 13:09:08 -0600 (CST) > From: Tim Salo <salo(a)networkcs.com> > To: nanog(a)merit.edu > Subject: Network Visualization > > We are looking for networks on which to deploy our network visualization > tool. Our focus is on IP networks that operate over underlying > connection-oriented networks such as ATM. For more information, see: > > http://www.msci.magic.net/visualization/Visualization.html I just corrected the permissions so that you can now download the applet that does the animation on this page. Sorry for the inconvenience, -tjs (Geez, it worked when we tried it...)

1 0

Re: ARIN whois
by Dean Anderson 25 Nov '99

25 Nov '99

I have never heard them say anything of the sort. I do know that ORBS is uncommonly good at blocking relays. Much, much better than RBL. One admin I talked to recently told me about 8 of 10 relayed spams were identified by ORBS. Of course, is ORBS that good, or is ORBS actually the source of the relay attacks? I think the latter. I know our attacks increased (started actually) after ORBS people started inciting attacks. If it weren't for ORBS there wouldn't be so many relay attacks. I think it would be helpful to block all traffic to ORBS as an organization that promotes and incites criminal activity. I think port scanning from ORBS into the US can be blocked immediately by any ISP as an unauthorized security scan, and a security attack. We block them not only from our servers, but all of our customers as well. Of course, they still advertise our servers to spammer and antispammer attackers. All I can do is keep listing them in our complaints to the FBI. But more complaints will help. --Dean At 03:19 AM 11/25/1999 +0300, Alex P. Rudnev supposedly said: >Btw. > >They, antispammers, have one usefull policy. Yes, you can keep OPEN RELAY, if >you agree to restrict RELAYING FROM the wrong (existing in the ORBS or other) >sources. > >It's just enougph for the business. > >Alex R. > > > >On Wed, 24 Nov 1999, Dean Anderson wrote: > >> Date: Wed, 24 Nov 1999 17:13:59 -0500 >> From: Dean Anderson <dean(a)av8.com> >> To: J.D. Falk <jdfalk(a)cybernothing.org>, nanog(a)merit.edu >> Subject: Re: ARIN whois >> >> >> I'm surprised to see such poorly considered statements from JD. >> >> Unless SMTP AUTH (just released in sendmail 3 weeks ago) works in every client, and is support in MS Exchange, then we (that is we as an operations community) don't have the technology to practically authenticate it yet. I too can write an authenticated SSL client & server to transfer mail between two computers. But its not useful unless its widely deployed. Statements to the contrary are just foolishness in an operational context such as a real business. We are running a _BUSINESS_, not a research lab, with one server and one specially developed client. >> >> We don't run relays out of laziness. We went out of our way to enable them. We go out of our way to monitor them for unauthorized use. We would certainly prefer an authenticated mail system. We have to live with what is currently deployed. >> >> What annoys me about the pressure from the junior antispammer league is they go from "gee, you know you can close those relays" >> >> We respond "Yes, we know. We operate them on purpose for business reasons". At times, I've explained these business reasons in detail. The technical conclusion is then that we have to operate relays. >> >> They then jump to "Thats unacceptable. You MUST CLOSE THEM". >> >> We say "No. Absolutely not." >> >> They say "Well, in that case we're going to start committing crimes against your service, posting to alt.2600, inciting attacks, and wasting your time, bandwidth, and computer resources until you agree to close them." >> >> We say, thats extortion. We say that crimes against our service are crimes. We report them, and they will get eventually get punished, and we will work hard to get paid for the services rendered and the damages done by criminals. We don't tolerate this sort of behavior. Most companies don't. >> >> --Dean >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Plain Aviation, Inc dean(a)av8.com >> LAN/WAN/UNIX/NT/TCPIP http://www.av8.com >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> > >Aleksei Roudnev, >(+1 415) 585-3489 /San Francisco CA/ > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

Re: Fwd: Bell Atlantic - Just a little congestion (corrected URL)
by Sean Donelan 24 Nov '99

24 Nov '99

>Is there a FCC URL where the required "oops" report will >appear? Well, there may not be any report filed. The FCC reporting criteria are designed for POTS failures, i.e. lots of analog phone lines. Although thousands of T3s were affected by this, its not clear if 30,000 customers were affected. Remember, resellers like Northpoint or an ISP only count as a single BA customer. Other carriers do the same thing. For example, as far as I can tell MCI Worldcom never filed an outage report for their frame-relay outage this summer, I suppose because only 3,000 customers were affected. And remember, it was just some "congestion," not an outage. If one is filed, it will show up at the following URL in 1-2 months. http://www.fcc.gov/Bureaus/Engineering_Technology/Filings/Network_Outage/

2 2