August 2001 - Test - lists.nanog.org

The Cidr Report
by CIDR Report 04 Aug '01

04 Aug '01

This is an auto-generated mail on Fri Aug 3 23:00:00 PDT 2001 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 03Aug01 0) General Status Table History ------------- Date Prefixes 270701 101541 280701 101451 290701 101356 300701 101504 310701 101910 010801 102050 020801 101595 030801 102236 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 67.0.0.0/16 from AS209 *** Bogus 82.104.0.0/16 from AS3269 *** Bogus 82.104.128.0/17 from AS3269 *** Bogus 82.105.0.0/16 from AS3269 *** Bogus 82.105.128.0/17 from AS3269 AS Summary ---------- Number of ASes in routing system: 11335 Number of ASes announcing only one prefix: 6741 (3853 cidr, 2888 classful) Largest number of cidr routes: 865 announced by AS701 Largest number of classful routes: 1411 announced by AS701 1) Gains by aggregating at the origin AS level --- 03Aug01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1321 983 338 25.6% Telstra Pty Ltd AS701 1411 1196 215 15.2% UUNET Technologies, Inc. AS2551 639 515 124 19.4% ICG NetAhead, Inc AS4151 273 152 121 44.3% USDA AS4293 386 277 109 28.2% Cable & Wireless USA AS6595 161 57 104 64.6% DoD Education Activity Network As AS6429 204 103 101 49.5% AT&T Chile Internet S.A. AS13999 104 8 96 92.3% Mega Cable S.A. de C.V. AS705 228 136 92 40.4% UUNET Technologies, Inc. AS4755 209 118 91 43.5% Videsh Sanchar Nigam Ltd. Autonom AS7018 719 630 89 12.4% AT&T AS19632 95 10 85 89.5% Metropolis Intercom S.A. AS8013 301 219 82 27.2% PSINet Ltd. Canada AS577 248 175 73 29.4% Bell Advanced Communications Inc. AS724 230 158 72 31.3% DLA Systems Automation Center AS16473 135 63 72 53.3% Bell South AS7046 313 246 67 21.4% UUNET Technologies, Inc. AS6471 123 59 64 52.0% ENTEL CHILE S.A. AS3464 152 91 61 40.1% Alabama SuperComputer Network AS4200 122 62 60 49.2% Apex Global Information Services, AS1239 457 399 58 12.7% Sprint AS12302 90 32 58 64.4% MobiFon S.A. AS16758 63 6 57 90.5% IKON Office Solutions AS1 557 502 55 9.9% BBN Planet AS3908 207 153 54 26.1% Supernet, Inc. AS226 145 92 53 36.6% Los Nettos AS6413 65 13 52 80.0% Southern Online Systems, Inc. AS703 301 250 51 16.9% UUNET Technologies, Inc. AS17561 112 61 51 45.5% Internet service provision to Wes AS852 215 165 50 23.3% Telus Advanced Communications 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: trapdoor.merit.edu and other impatient Postfix mailers everywhere
by Larry Sheldon 03 Aug '01

03 Aug '01

Heh. I just said: > Would y'all please leave me off the "Cc: " list--especially of nanog is > on it. And then did it to myself! It has been a very long week. > Thanks a lot. > > Peace.

1 0

RE: trapdoor.merit.edu and other impatient Postfix mailers everywhere (fwd)
by Larry Sheldon 03 Aug '01

03 Aug '01

> I understand they have a problem notifying everyone since they don't > know contact information for the people using the service, but I would > have expected to see an announcement here, for example. Lemesee if I got this right...Paul Vixie doesn't know anybody that can pull my IP addresses out of their logs, look them up on ARIN, send me email. Riiight. GMAB! > How do you think those references got there? Could it be that enough > people requested it and asked how to do it with older versions of > sendmail that it was made an optional part of the standard configuration? Probably not. Can you say "bait and switch", boys and girls. Right out of Mad Man Muntz's handbook.

11 14

Northern VA - Its not a worm, just Mother Nature
by Karl 03 Aug '01

03 Aug '01

------ Original message: -------------- > To: nanog(a)merit.edu > From: Sean Donelan <sean(a)donelan.com> > Subject: Its not a worm, just Mother Nature > > > Yesterday, Chicago and the midwest was hit by severe thunderstorms. > Power was disrupted in several cities, and even now at least one > provider still recovering somewhere in the Detroit, Chicago, Cleveland > area. Today, Florida is getting hit with a tropical storm. A couple > of providers seem to have a few connectivity problems. It seems that Nextel/Motorola and Verizon are having troubles in various parts of Northern VA. I just got off phone with Nextel and Verizon, and seems that there have been power outages or generator failures, and some of their equipment, picking up the flack, is overloaded. Verizon and Motorola were dispatched to Reston, where there were some RF errors on the Nextel switches. Maybe someone on the list can verify or negate these reports from Nextel. I don't mean to imply that this Friday afternoon, Northern-VA outage is directly related to the Florida hurricane, but -- certainly -- the heat, humidity, and overwhelming use of air-conditioners can be considered climactic fallout. -Karl Systems Administrator, ARIN.net --------------------------------------------

2 1

Its not a worm, just Mother Nature
by Sean Donelan 03 Aug '01

03 Aug '01

Yesterday, Chicago and the midwest was hit by severe thunderstorms. Power was disrupted in several cities, and even now at least one provider still recovering somewhere in the Detroit, Chicago, Cleveland area. Today, Florida is getting hit with a tropical storm. A couple of providers seem to have a few connectivity problems. Pretty much another day on the Internet.

1 0

Clarification of need for Fast Ethernet @ 60 Hudson St
by doug healy 03 Aug '01

03 Aug '01

Sorry I wasn't more specific in my original post. We are looking for a Fast Ehternet drop with IP service. Thanks Doug Healy Streampipe Inc doug(a)streampipe.com

1 0

RE: handling Sircam and the like from the e-mail service operator 's perspective...
by Roeland Meyer 03 Aug '01

03 Aug '01

> -----Original Message----- > From: woods(a)weird.com [mailto:woods@weird.com] > Sent: Friday, August 03, 2001 9:32 AM > I'm beginning to find that some of my clients who operate e-mail > services are facing some very real ongoing operational issues with the > likes of the Sircam worm/Trojan. At the moment the clients with the > most pressing problem is a small cable-modem and dial-up operator. > > So far I've been advising all of my clients to treat these kinds of > worms as valid e-mail and to simply help their end users, where > possible, to eliminate it and deal with its impacts. I.e. if we're > going to accept any e-mail from a given SMTP client to a > given recipient > then we accept it and deliver it without regard to its content. That last part is the problem. Why not filter on SirCam, at the mail host? We had to do the LoveBug and it worked well. The issues were almost identical, except that LoveBug was smaller. > We're working under the general assumption that a large > segment of these > users would undoubtably become very angry if we simply > filtered out all > attachments, or even just those with filename extensions that losing > software might try to "execute" (though in general that means anything > that might include "macros" with the data too!), however I > don't see any > other manageable way to stop this kind of attack (other than > eliminating > or fixing all of the broken software that can be exploited in > this way!). Run virus scanners on all inbound mail. Yes, I know that burns CPU cycles like mad. It does a pretty good job of thrashing DASD as well. > We're also working under the general assumption that a large > segment of > these users would become very angry if we dropped the maximum message > size to a limit that at least Sircam and its ilk couldn't quickly > overflow our average mailbox quotas. We've done this temporarily > overnight and over weekends before we upgraded system capacities, and > that did cause a lot of extra load on the support lines, but > it stopped > transmission of at least Sircam in its tracks (being it's > always >135KB). > My clients will generally be able to manage the expectations of their > users better if they can point to other larger service > providers who've > taken equally, or more, draconian measures.... :-) Since you have a working signature, for SirCam, why not use it in production?

1 0

Need Fast E drop @ 60 Hudson St NY
by doug healy 03 Aug '01

03 Aug '01

We are looking for a Fast Ethernet drop at 60 Hudson St NY. Please feel free to respond in private Email Thanks Doug Healy Streampipe Inc doug(a)streampipe.com

1 0

Re: trapdoor.merit.edu and other impatient Postfix mailers everywhere (fwd)
by Larry Sheldon 03 Aug '01

03 Aug '01

> It is interesting to see some of the sites that not only use(d) the MAPS > lists for free, but didn't even bother to do the zone transfer mode > (which reduces the load on the MAPS servers and speeds up your local > use). At least one of us thinks the zone transfer mode was not free; and, at least one of us thinks the sendmail configuration we were using was taken from the vix.com site as is. At least one of us has a reputation for being wrong from time to time.

22 36

handling Sircam and the like from the e-mail service operator's perspective...
by woods＠weird.com 03 Aug '01

03 Aug '01

I'm beginning to find that some of my clients who operate e-mail services are facing some very real ongoing operational issues with the likes of the Sircam worm/Trojan. At the moment the clients with the most pressing problem is a small cable-modem and dial-up operator. So far I've been advising all of my clients to treat these kinds of worms as valid e-mail and to simply help their end users, where possible, to eliminate it and deal with its impacts. I.e. if we're going to accept any e-mail from a given SMTP client to a given recipient then we accept it and deliver it without regard to its content. Now that we've ironed out tuning and configuration issues so that our systems can actually handle the increased SMTP load, especially that caused by Sircam in particular, we're finding that our users simply can't handle the load. There are far more users with constantly over-quota mailboxes (Sircam being particularly evil at sending large files). This is just as effective a denial of service for those users as any failure in the SMTP transport or mailbox access protocols would be. The users can still retrieve what e-mail they receive just fine, even most of the dial-up users, but there's so much of it now that most users, especially home users, don't keep up with the flow. Last night alone (eg. over an ~12hr period) we had over 1000 copies of the Sircam worm itself (with attached files, of course) dumped into the error queue because both the sender's and the recipient's mailboxes were over quota (and of course not all the senders were local either). I've given up counting the number of copies that have likely been delivered -- it's just way too many to comprehend. We're working under the general assumption that a large segment of these users would undoubtably become very angry if we simply filtered out all attachments, or even just those with filename extensions that losing software might try to "execute" (though in general that means anything that might include "macros" with the data too!), however I don't see any other manageable way to stop this kind of attack (other than eliminating or fixing all of the broken software that can be exploited in this way!). We're also working under the general assumption that a large segment of these users would become very angry if we dropped the maximum message size to a limit that at least Sircam and its ilk couldn't quickly overflow our average mailbox quotas. We've done this temporarily overnight and over weekends before we upgraded system capacities, and that did cause a lot of extra load on the support lines, but it stopped transmission of at least Sircam in its tracks (being it's always >135KB). How many of you who are also operators of e-mail services including mailboxes have implemented (for your customer mailboxes) such draconian indiscriminate attachment filters; and/or lowered your maximum allowed message size to something that would once upon a time have been considered overly generous, such as 100-150KB or so? How many of you have implemented more selective signature-based filtering, and of you how many are paying some (hopefully respected and trusted) third party to access regular updates of the signature list? How many of you consider signature based filtering to be bogus even though it would mostly mitigate the ongoing after-effects of something nasty like Sircam? How many of you have implemented per-mailbox restrictions so that end users must choose for themselves whether or not they'll ignore/drop/reject some of their e-mail? Please respond with any basic yes/no answers directly to me (if you can! ;-), and I'll post a followup summary by Tuesday or so if there's anything significant. My clients will generally be able to manage the expectations of their users better if they can point to other larger service providers who've taken equally, or more, draconian measures.... :-) ("I'm too scared to jump! Why don't the big boys jump first?" ;-) I've seen some de-fanged copies of Sircam that still matched my primitive signature check from Yahoo.... -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods(a)acm.org> <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com>

1 0