February 2000 - Test - lists.nanog.org

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

and we worry about route table bloat with micro-alloc ????
by John M. Brown 24 Feb '00

24 Feb '00

*> 12.2.19.0/25 166.48.176.25 0 3561 11277 i *> 12.16.207.0/25 166.48.176.25 0 3561 7217 i

3 2

[IOZ] SDN/Telkom - details for Summit TV
by Randy Bush 24 Feb '00

24 Feb '00

i abhor cross-posting. but sometimes ... if you think we have problems with telcos, ... from south africa ------ From: "Peter Lewis" <peter(a)sdn.co.za> To: <ioz(a)internet.org.za> Subject: [IOZ] SDN/Telkom - details for Summit TV Date: Thu, 24 Feb 2000 13:30:14 +0200 Message-ID: <0cf701bf7eba$851b29f0$4302a8c0(a)sdn.co.za> here are some of the points about the story: - Telkom unlawfully suspended SDN's backbone (this obviously brought all of SDN's clients down as well) - Telkom also unlawfully suspended the clients' own circuits, despite the fact that these are paid for directly by the client and do not involve SDN - Telkom cited non-payment as the reason for suspension of services, despite the fact that when a reconciliation was done, SDN is actually R87, 000 in credit - SDN's attorneys applied for interim relief against the suspension of services - at 03h00 this morning, a judge found in favour of SDN and passed a court order for Telkom to turn the services back on - Telkom defied the court order and did not resume services within the stipulated 2 hours - Telkom is currently opposing the court order on the basis of jurisdiction, and a decision will be out later today regards Lorna Gray Tin Can Communications Tel: +27 11 463 8480 Peter Lewis Director Satellite Data Networks (Pty) Ltd Tel: 011 88 00 55 7 Fax 011 88 09 76 6 Cell 082 781 5590

1 0

Congress to Hold Hearings on DOS Attacks
by Robert Cannon 24 Feb '00

24 Feb '00

The Senate Committee on the Judiciary Subcommittee on Technology, Terrorism and Government Information will hold a hearing on Tuesday, February 29, 2000, at 2:00 p.m. in Room 226 of the Senate Dirksen Office Building on "Cyber Attacks: Vulnerability Warnings Unheeded ." Senator Kyl will preside. By order of the Chairman The Senate Committee on the Judiciary Subcommittee on Criminal Justice Oversight will hold a joint hearing with the House Judiciary Subcommittee on Crime, on Tuesday, February 29, 2000, at 2:00 p.m. in Rayburn HOB Room 2141 on "Internet Denial of Service Attacks and the Federal Response ." By order of the Chairman R Cannon cannon(a)world.oberlin.edu www.cybertelecom.org ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com?sr=mc.mk.mcm.tag001

1 0