- NANOG - lists.nanog.org

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

mail relay thread
by Larry Snyder 26 Nov '99

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

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

25 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

Bell Atlantic FCC outage report available now
by Sean Donelan 24 Nov '99

24 Nov '99

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…

1 0