- Test - lists.nanog.org

Locked out?
by Sean Donelan 29 Nov '99

29 Nov '99

A person sent me a pointer to the happenings at the Everquest data center on Saturday. Yet another person learns the joy of electronic door systems :-) http://everquest.station.sony.com/network_fs.html Another commonly overlooked system is a building's paging system. They are often handled by different groups, and aren't included in the systems backup plan. Fortuantely most people figure out workarounds quickly. Yep, I found out the hard way too.

1 0

What happened to the hosting infrastructure maps
by Henry R. Linneweh 29 Nov '99

29 Nov '99

for the USA and Europe this link is dead http://www.bbnplanet.com/products/maps/us_host.htm -- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

1 0

Bell Atlantic FCC outage report available now
by Alex Rubenstein 28 Nov '99

28 Nov '99

Does anyone find it even remotely interesting that Bell Atl had an outage, performing a similar upgrade to a similar piece of equipment (Alcatel IMTN), only three days earlier in Philadelphia? http://www.fcc.gov/Bureaus/Engineering_Technology/Filings/Network_Outage/19… For once, I wish someone in the press would pick up how much the telco's suck, and try to hide significant events like this; especially this north jersey one where they said only three counties were affected! Bah! The entire LATA was affected! ---------- Forwarded message ---------- Date: 24 Nov 1999 13:13:16 -0800 From: Sean Donelan <sean(a)donelan.com> To: nanog(a)merit.edu Subject: Bell Atlantic FCC outage report available now Ah, I see my friends at the FCC are reading this list. The Bell Atlantic FCC outage report for the Nov 23 New Jersey outage has been scanned, and is online at the FCC web site. http://www.fcc.gov/Bureaus/Engineering_Technology/Filings/Network_Outage/19… --------------------------------------------------------------------- To unsubscribe, e-mail: internal-unsubscribe(a)nac.net For additional commands, e-mail: internal-help(a)nac.net

5 6

Voluntary outage report, who gets blamed
by Sean Donelan 28 Nov '99

28 Nov '99

Robert Cannon <rmcannon(a)mail.com> writes: >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. Of course, some large companies will continue their current practice of keeping bad news quiet. But my intent hasn't been to point out how bad some companies are. My concern is the wild, unregulated Internet gets blamed for a lot of outages which really aren't "Internet" outages. In the last two weeks I've only noticed three multi-hour multi-ISP affecting incidents: 1) a misconfigured router in Dallas spewed bogus routing information, 2) an ILEC's DACS lost its configuration in New Jersey, and 3) a MAE had a loopback which caused "network congestion" and routes to flap for a few hours. There were other problems, a couple of fiber cuts and power failures, but they didn't seem to cause problems for multiple ISPs. Interestingly enough problem 1 affected multi-homed networks more than single homed networks, which happen also to house the most popular web services. With so much hype this month about web retailers and the christmas shopping season, some very high profile sites have been hit by various problems and covered by the news media. However, just because a credit card processor goes down, and many web sites were shutdown, does not mean its an "Internet" problem. Its a credit card processor problem. As I poked around several of the problems over the last couple of weeks, I found most web site outages related to "back-end services." Problems with their database software, disk and server farms, and the ever popular "operator error." Yes, some network problems happened. But ISPs are getting pretty good at the packet delivery stuff. The ISP can usually deliver more packets than the server can handle :-) Perhaps surprising, but since some folks are concerned e-commerce is where the money is, none of the problem e-commerce web sites with whom I spoke or read about attributed any down time to criminal or "cracker" activity. But it may be a self-selecting group. Maybe the reason some people wouldn't answer my questions was because their outages did involve suspicious activity.

1 0

Re: ARIN whois
by Dean Anderson 28 Nov '99

28 Nov '99

Option 3. Invoice them for services. Send a demand letter for services rendered, and tell them to refrain from further relaying until payment terms are arranged. Send the letter certified return receipt to the corporate agent. If the services rendered exceed $5000, report the act to the FBI. To make an effective criminal complaint that can be prosecuted, you need to make efforts to collect the money. After the demand letter, engage a lawyer to sue them, or a collection agency to collect the money. Before ORBS and the antispammers started inciting attacks this summer, spammers did not find our service. Anyone that runs an active probe service on a leased line would be discovered, and shutdown. You aren't going to probe much of the internet on a dialin line. We know how to stop people on static IP addresses. Criminal relaying depends on a service like ORBS to collect and disseminate information on where to find a relay. This is why we ask all operators to block traffic to ORBS, which has recently changed addresses to 202.36.147.16. We had blocked 202.36.148/24. I just noticed they changed IP addresses to avoid filters. These are our new filters: access-list 104 deny ip 202.36.148.5 0.0.0.255 any access-list 104 deny ip 202.36.147.16 0.0.0.255 any Slippery. But these two /24's appears to be all that is swipped to them. I want to offer my heartfelt thanks to all operators who have blocked them so far. This holiday weekend has certainly been better. --Dean Around 10:42 AM 11/27/1999 -0600, rumor has it that Gene Black said: >That's why you engineer around the problem to insure that your >legitimate business can continue when you shut down your relays. If you >leave them open long enough, the spammers will eventually find you, and >when they do, you're only going to have two options left: > >1. Close the relays > >or > >2. Quit offering any type of SMTP services. > >This is what prompted us to close our relays a few years back. The sheer >amount of spam coming through was so massive as to effectively shut down >our mail servers and eat a very significant portion of our bandwidth. >Users won't tolerate outages like that - and shouldn't have to. The >majority of it was coming in from remote places overseas as well - not >the sort of thing that you can easily pursue legally if you can pursue >it at all. > >Just my two cents... > > >"Roeland M.J. Meyer" wrote: >> >> You have just explained why you are a SysAdmin and not a business operator. >> The issue is not that closing them is difficult. The issue is that it will >> ALSO close down a legitimate business. >> >> > -----Original Message----- >> > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of >> > Robert Gash >> > Sent: Monday, November 22, 1999 12:45 PM >> > To: Dean Anderson >> > Cc: nanog(a)merit.edu >> > Subject: Re: ARIN whois >> > >> > >> > >> > Dean, perhaps I am not fully understanding your logic behind >> > not closing >> > your relays. I have been a systems administrator for 4 years >> > and I have >> > not ever found an application where I needed to leave my SMTP >> > relays open >> > to the world. I do not doubt that you have legitimate >> > business purposes >> > in mind when opening your relay, but at some point you must >> > decide that >> > legal action will be too slow to fix anything and that it >> > might be a good >> > time to close your relays to aleviate other problems. Simply >> > saying "I >> > shouldn't need locks on my doors because everyone should be >> > honest and never come into my house without my permission," >> > dosen't cut it >> > in this world, and I am quite sure that you have >> > locks on every portal to your house, so why should your SMTP >> > server be any >> > different? Taking such a stance and refusing to close your >> > relays is simply a foolish decision. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

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 26 Nov '99

26 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