- Test - lists.nanog.org

To AOL engineers (icq services)
by Dmitry Safronov 28 Feb '00

28 Feb '00

Hello , Maybe some people from AOL routing engineers are reading this list... The following question for them... From adresses 195.161.0.0/16 and 213.24.0.0/16 we cannot connect to http port on your web sites: www.icq.com www.icq.net www.mirabilis.com and ICQ servers. But from my client's addresses (other blocks) we can. It seems like AOL filtered out our address blocks with port 80. Could anyone from AOL engineers help to solve the situation? Best regards, _____________________________________________________________________ Dmitry Safronov Rostelecom/Internet Centre Tel: +007 (095) 334-9983 Fax: +007 (095) 339-2415

1 0

Need routing engineer from Verio
by Rizzo, Mark 27 Feb '00

27 Feb '00

Hello, I need to contact someone from Verio that can help me sort out a routing issue between Verio and my company. Thanks, Mark Rizzo EA.COM

3 2

Fwd: [cfgeeks] TOOLS FOR VANDALS
by Shawn McMahon 26 Feb '00

26 Feb '00

I told you guys, but only some of you listened. It is not only possible to launch an attack like this from home user's PCs, "rewted" by amateurs, but it looks like a part of this was indeed done that way. This mess is gonna suck to clean up. Thanks, Microsoft, for all your help. Too bad you were helping the wrong effing side... >From: "Kevin P. Inscoe" <kevin(a)inscoe.org> >Reply-To: cfgeeks(a)onelist.com >Subject: [cfgeeks] TOOLS FOR VANDALS > >From: "Kevin P. Inscoe" <kevin(a)inscoe.org> > >TOOLS FOR VANDALS >San Jose, California-based Finjan software says that new hacker software >called Trinoo "zombie" can be run from ordinary PCs running Microsoft >Windows and will not require high-end Unix workstations of the sort that >have been involved in previous vandal attacks made through the Internet >against corporate and government computers. Vandals would be able to >launch >distributed denial-of-service attacks much more easily, preventing >people >from visiting the targeted sites. (Bloomberg News/New York Times 25 Feb >2000) >http://www.nytimes.com/library/tech/00/02/biztech/articles/25hack-pc.html > >~kevin >-- >Kevin P. Inscoe Unix System Engineer & Specialist >Deltona, FL Itinerary at http://www.inscoe.org/where >e-mail: kevin [at] inscoe [dot] org >http://www.inscoe.org 28.9492N 81.1955W >http://www.inscoe.org/comp http://www.inscoe.org/radio > >Where the Central Florida geeks hang out... >http://www.onelist.com/community/cfgeeks >Kevin Inscoe (kevin(a)inscoe.org) - Listmom

2 1

Congestion strikes British Telecom
by Sean Donelan 26 Feb '00

26 Feb '00

According to the BBC, two out of three main switches which handle 0800 and other national numbers crashed on Friday. This lead to congestion on numbers used for help lines and dialup lines for Internet service providers. Due to BT charges, most british ISPs use special numbers instead of local numbers. ISPs said they didn't get a lot of phone calls from customers complaining. But since ISP customer service numbers tend to be 0800 numbers (similar to 1-800 numbers in the states), more than likely even if customers wanted to complain, they couldn't reach the ISP. I couldn't find any information about the outage on the BT web site, but BBC has the story at http://news.bbc.co.uk/hi/english/uk/newsid_657000/657449.stm Yes, I know the telephone companies pride themselves on the unfailing nature of their networks. They never crash, just a bit of congestion. However, if you are using one of these new-fangle 800 services, I suggest you also have a regular international direct dial number for your customer service and network operations centers.

1 0

APC MasterSwitches, lock up on DOS attacks
by John M. Brown 26 Feb '00

26 Feb '00

According to APC Technical support (called them today), if you have a APC master switch and it see more that 200-300 packets per sec on its interface it will lock up the unit. The newer units will exhibit the same condition if you send more than around 2000 to 3000 packets per second. We saw this as our units would drop of the net from time to time. They (APC) have no fix for this issue, nor do they have an upgrade path, other than buying a newer unit, for the older systems. Units are not flashable as they use a 27xxx series EPROM on the micro controller card. YUK

3 2

The Cidr Report
by Tony Bates 25 Feb '00

25 Feb '00

This is an auto-generated mail on Fri Feb 25 12:00:00 PST 2000 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 25Feb00 0) General Status Table History ------------- Date Prefixes 180200 72321 190200 72203 200200 72346 210200 72296 220200 72419 230200 72364 240200 72455 250200 72608 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.45.0.0/19 from AS10585 *** Bogus 99.0.0.0 from AS9841 *** Bogus 219.91.160.0/22 from AS7742 *** Bogus 219.91.164.0/23 from AS7742 AS Summary ---------- Number of ASes in routing system: 6762 Number of ASes announcing only one prefix: 3701 (2011 cidr, 1690 classful) Largest number of cidr routes: 774 announced by AS701 Largest number of classful routes: 1009 announced by AS701 1) Gains by aggregating at the origin AS level --- 25Feb00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 437 152 285 65.2% BCnet Backbone AS7046 438 292 146 33.3% UUNET-CUSTOMER AS1221 657 523 134 20.4% TELSTRA-AS AS9269 154 26 128 83.1% Hong Kong CTI AS9706 151 26 125 82.8% Pusan Metropolitan City Office of AS2609 122 23 99 81.1% EUnet-TN AS4293 272 177 95 34.9% Internal ASN for C&W AS2715 157 62 95 60.5% REDERIO-AS AS7657 274 181 93 33.9% The Internet Group Limited AS7545 154 61 93 60.4% TPG Internet Pty Ltd AS7496 124 38 86 69.4% Power Up AS6429 203 118 85 41.9% RDC-INTERNET AS174 553 471 82 14.8% Performance Systems International AS705 291 212 79 27.1% ALTERNET-AS AS9304 101 23 78 77.2% Hutchcity AS3749 137 61 76 55.5% TECNET AS577 245 172 73 29.8% Bell Backbone AS3602 326 253 73 22.4% Sprint Canada Inc. AS816 369 306 63 17.1% UUNET Canada (ASN-UUNETCA-AS4) AS4200 167 104 63 37.7% AGIS (Apex Global Information Ser AS7029 111 50 61 55.0% ALLTELNET AS4740 337 279 58 17.2% Ozemail Pty Ltd (ASN-OZEMAIL) AS1727 134 77 57 42.5% MRMS-WEST AS7260 103 48 55 53.4% NORLIGHT AS209 385 335 50 13.0% Qwest Communications AS9557 73 26 47 64.4% Pakistan Telecommunication Compan AS701 1009 962 47 4.7% Alternet AS2652 126 81 45 35.7% Government of Canada Telecommunic AS684 86 44 42 48.8% Manitoba Regional Network Backbon AS6528 48 6 42 87.5% WORLD-LYNX 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: government eavesdropping
by michael.dillon＠gtsip.net 25 Feb '00

25 Feb '00

On Fri, 25 February 2000, owen(a)exodus.net wrote: > Except that for the most part, MAE connections are switched, not "shared" > media. As such, they'll see Broadcasts, and packets destined for the > monitoring equipment and little else. The aggregate bandwidth of the MAE > makes them using a SPAN port virtually impossible. If memory serves, the > MAE traffic is several times 100Mbps. SPAN ports were not always infeasible and certainly are quite feasible at a lot of smaller exchange points. And all kinds of things could be happening inside an ATM exchange. And the spooks are happy to get any traffic at all; they don't need 100% of it and cannot get 100% of it in today's Internet structure. All they need is a little inside help to get great piles of interesting traffic from taps within a large provider or within an exchange point. And there is still the possibility of tapping the fiber directly at least two ways that I know of. Governments spying on their citizenry is just a fact of life in the modern age. The key thing is to make sure that they do not abuse this power or this data but that is politics, not technology. --- Michael Dillon Phone: +44 (20) 7769 8489 Mobile: +44 (79) 7099 2658 Director of Product Engineering, GTS IP Services 151 Shaftesbury Ave. London WC2H 8AL UK

2 1

Re: government eavesdropping
by michael.dillon＠gtsip.net 25 Feb '00

25 Feb '00

On Fri, 25 February 2000, Kai Schlichting wrote: > >The US government has had listening devices at the MAEs/NAPs for years. > If there is really a number of such IMHO unlawful taps, it'll be hard to > contain information about them, unless they've dug themselves close to the > fiber and are bending & eavesdropping that fiber outside of the MAEs. They do that too, but installing a tap at an exchange point that uses a shared media is as simple as wheeling in a Cisco chassis with a FDDI or Ethernet port on it. Not that the chassis necessarily contains any Cisco equipment, of course. > Such taps are not trivial, and their physical dimensions make it hard > to hide them to the trained fiber installer's eye. Fiber does make the eavesdropper's job harder but they don't necessarily need to tap 100% of the traffic to get useful data. > And then there was the story of a german company producing devices > Needless to say this company is a very eager user of Swiss-made > encryption products at this point. Obviously this German company is not aware of how the German intelligence service, in cooperation with the Israeli intelligence service, infiltrated a Swiss encryption company and crippled the encryption technology by not using all the bits of the key. This made the encryption crackable by the computers in use by the NSA at the time. > ps: reportedly, NDB.com got DDOS'd today. Overloading the NSA's illegal > eavesdropping taps one at a time. What makes you think that the NSA doesn't already have a solution to the DOS problem? After all, they've known about this stuff for about 20 years. --- Michael Dillon Phone: +44 (20) 7769 8489 Mobile: +44 (79) 7099 2658 Director of Product Engineering, GTS IP Services 151 Shaftesbury Ave. London WC2H 8AL UK

1 0

TOS history?
by Dana Hudes 24 Feb '00

24 Feb '00

Hi folks, I'm busily writing up my next lecture for my TCP/IP course at CUNY Hunter (text is Comer vol. 1 4th edition), the topic is the base Internet Protocol datagram format. I come to the TOS field which, as all know, was originally specified in the base IP specification RFC 791 then attempt to extend and reconcile it with later RFCs made in RFC 1349 followed subsequently in RFC 2474 in late 1998 which completely changed it to support DiffServ. In RFC 791 on page 11, Jon Postel writes: Several networks offer service precedence, which somehow treats high precedence traffic as more important than other traffic (generally by accepting only traffic above a certain precedence at time of high load). The major choice is a three way tradeoff between low-delay, high-reliability, and high-throughput. Was this something actually supported in the Internet? Widely? any examples of who? Around when did it stop being supported? Did anyone ever actually support RFC1349 in a host or router? How about DiffServ as specified in 2474 and 2475? I believe there are router implementations but is anyone actually got it turned on ? Possibly only in an IP "intranet"? Dana Hudes CSCI Dept CUNY Hunter College

3 3

DDOS Roadmap from SANS...
by Valdis.Kletnieks＠vt.edu 24 Feb '00

24 Feb '00

Nothing in here should come as a surprise to anybody on this list, but... http://www.sans.org/ddos_roadmap.htm -- Valdis Kletnieks Operating Systems Analyst Virginia Tech

3 3