December 2001 - Test - lists.nanog.org

black hat .cn networks
by Dan Hollis 08 Mar '02

08 Mar '02

http://wired.com/news/politics/0,1283,43437,00.html Time to drop AS4134. -Dan

16 17

Re: Automated DLR conflict detection
by Steven M. Bellovin 03 Jan '02

03 Jan '02

In message <Pine.GSO.4.40.0112290239530.29284-100000(a)clifden.donelan.com>, Sean Donelan writes: > > >On Sun, 23 Dec 2001, Peter Galbavy wrote: >> You misunderstand. Which operators will offer this (backed by some >> underwritten insurance) in an effort to be better than the competition ? > >Buying car insurance doesn't alter the chances of your car breaking >down on a long trip. Insurance doesn't alter the chances of something >bad happening. Driver training, seat belts, and spare tires are things >which can reduce risk. Yes, but insurance companies often move in and set certain behavioral requirements as a coverage requirement, just to cut their own payouts. To give just a couple of examples, both Underwriters' Laboratories and the National Electrical Code are spinoffs of the insurance industry. To return to your analogy, maybe you can only buy car insurance, or buy it at a reasonable rate, if you first bring your car in for a checkup and replace the bald tires. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

12 15

OUTAGE: five bridges across Mississippi destroyed
by Sean Donelan 31 Dec '01

31 Dec '01

Now that I have your attention. My intent with the DLR discussion was to find out how we can estimate, predict, simulate how robust the Internet really is; not debate vendor certifications. Several telephone companies, working together, simulated what would happen to the public telephone network if five bridges across the Mississippi river carrying fiber optic lines were destroyed. The result was the public telephone network was unaffected, according to the participating telephone companies. I believe this was considered the worst scenario at the time. Has anyone, or any group of ISPs done a similar analysis for data and Internet traffic?

3 2

Clueful Verio contact?
by Stanley, Jon 31 Dec '01

31 Dec '01

I just attempted calling the Verio NOC (we are not a customer or peer) because they are leaking our IP space (204.194.10.0/24 to be exact). This space contains nntp2.savvis.net, among other things, so obviously this is something of a problem for us. The response that I got from Verio was first to email their abuse department. After making clear that it was not an abuse issue, but rather a BGP misconfiguration, they told me that they do not support BGP, though customers may use it if they want. At any rate, the leak needs to stop. Could someone from Verio either contact me off list, or just stop the leak? Thanks!

1 0

RE: Automated DLR conflict detection
by Kevin Gannon 31 Dec '01

31 Dec '01

-----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of EA Louie Sent: 31 December 2001 08:01 To: nanog(a)merit.edu Subject: Re: Automated DLR conflict detection ----- Original Message ----- From: "Jesper Skriver" <jesper(a)skriver.dk> > > > > Actually I would be much happy with a Certified something. I can't > > figure out why people want a CCIE to run their Juniper routers. > > Because a CCIE is about a lot more than knowing how to configure a Cisco > device, very few will pass a CCIE test without _knowing_ the technology, > and what they are doing, and that is the same regardless of the label on > the equipment. That may have been true during your genre of CCIE's, but not with the latest round of CCIE's, my friends... you should see the posts I see on the ccie lab mailing lists. Its enough to scare even me, and I don't scare easily. The latest round of study materials is creating a "puppy mill" of CCIEs - inexperienced, money-hungry, power-conscious, and absolutely clueless. I wouldn't give most of them the enable passwords to my routers... I agree that certainly the newer CCIE trend is for money as fast as possible and I have meet some of the newer CCIE's and ....... However something to note is the vast amount of CCIE's work for Gold Partners in these kind of environments it is very hard to hide. Of the better CCIE's I have worked with they tend to be very down to earth. I have meet some very self important guys as well, these tend to have something to hide. Many seem to have a problem saying "I dont know" the betters ones can say I dont know but they will find out for you. I hope to be joining the "puppy mill" soon and if I get power consciuos my peers will be quick to give me a kick back to relatity. Regards, Kevin ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. For more information contact postmaster(a)lancomms.ie phone + 353 1 4093000 fax + 353 1 4093001 **********************************************************************

1 0

RE: Automated DLR conflict detection
by Kevin Gannon 31 Dec '01

31 Dec '01

Guys sorry to jump in mid thread, however some of you might know how do the voice carriers handle SLA's. I know our telco voice guys seem to live on SLA's. I can not rember the last time there was any kind of widespread voice outage on an international network. Regards, Kevin -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Peter Galbavy Sent: 29 December 2001 09:35 To: Sean Donelan Cc: nanog(a)merit.edu Subject: Re: Automated DLR conflict detection > On Sun, 23 Dec 2001, Peter Galbavy wrote: > > You misunderstand. Which operators will offer this (backed by some > > underwritten insurance) in an effort to be better than the competition ? > > Buying car insurance doesn't alter the chances of your car breaking > down on a long trip. Insurance doesn't alter the chances of something > bad happening. Driver training, seat belts, and spare tires are things > which can reduce risk. > > A warranty is not a substitute for due dilegence. > > How can you perform due dilegence on a carrier? With a car, you > can open the trunk and check the spare tire. What is the best way > to check a spare circuit? To me, the diverse route *is* the safety belt. If it does not work when it is supposed to, I (or my mourning relatives) will sue the car companies arse off - if the attribution for the failure rests with a design of manufacturing flaw. Safety / Seat belts are not decoration - and neither should a diverse route or protection circuit be. (Yes, my English can boldly go... but I am still waiting for the coffee to finish.) Peter ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. For more information contact postmaster(a)lancomms.ie phone + 353 1 4093000 fax + 353 1 4093001 **********************************************************************

2 1

Re: microsoft
by Christopher Schulte 29 Dec '01

29 Dec '01

At 12:21 PM 12/28/2001 -0500, Ian A Finlay wrote: >Can anyone shed light here? 1) Both of the listed Nameservers for windowsupdate.microsoft.com timed out when I sent them non recursive DNS requests. 2) I killed my DNS cache, and asked again for the NS records for windowsupdate.microsoft.com. A new third one was listed, and one of the original servers began to respond. 3) Another reload shows only 2 servers listed again, and they both respond. Looks to me as if Microsoft is altering global delegation of their windowsupdate service. Maybe diversifying the dns structure as they did with microsoft.com after the attacks a while back? They now have 12 DNS servers scattered around the globe, just to serve microsoft.com dns. >iaf@duwo/iaf 148=>nslookup >Default Server: duwo.pair.com >Address: 209.68.2.64 > > > windowsupdate.microsoft.com >Server: duwo.pair.com >Address: 209.68.2.64 > >*** duwo.pair.com can't find windowsupdate.microsoft.com: Non-existent >host/domain >-Ian

5 6

RE: Automated DLR conflict detection
by Marc Pierrat 29 Dec '01

29 Dec '01

-----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Peter Galbavy Sent: Friday, December 21, 2001 5:47 AM To: Sean Donelan; nanog(a)merit.edu Subject: Re: Automated DLR conflict detection >On many occasions in my prior life at Demon Internet we laughed sales people >out of meetings when they offered SLAs that were limited to the value of a >months service. But, in the end *all* the salepeople offered the same deal. >Until when SLAs come with a pay back greater than the cost of the contract, >and in fact cover consequential losses, most service providers will treat >the failure to deliver within the SLA as a risk associated with the service >and not something more serious. However: Would you (or anyone in the group) be willing to pay a premium for that, and how much is a "real" SLA, one covering consequential losses, worth to you? Marc Pierrat marc(a)sunchar.com www.sunchar.com

5 6

The Cidr Report
by CIDR Report 29 Dec '01

29 Dec '01

This is an auto-generated mail on Fri Dec 28 23:00:01 PST 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 28Dec01 0) General Status Table History ------------- Date Prefixes 211201 104932 221201 104791 231201 104801 241201 104769 251201 104805 261201 104705 271201 104655 281201 104604 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 12178 Number of ASes announcing only one prefix: 7353 (4159 cidr, 3194 classful) Largest number of cidr routes: 768 announced by AS701 Largest number of classful routes: 1362 announced by AS701 1) Gains by aggregating at the origin AS level --- 28Dec01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1178 908 270 22.9% Telstra Pty Ltd AS701 1362 1132 230 16.9% UUNET Technologies, Inc. AS4151 292 158 134 45.9% USDA AS577 319 195 124 38.9% Bell Advanced Communications Inc. AS16473 198 77 121 61.1% Bell South AS7018 812 696 116 14.3% AT&T AS705 284 181 103 36.3% UUNET Technologies, Inc. AS852 410 312 98 23.9% Telus Advanced Communications AS6595 147 50 97 66.0% DoD Education Activity Network As AS17557 169 82 87 51.5% Pakistan Telecom AS7046 308 222 86 27.9% UUNET Technologies, Inc. AS19632 93 10 83 89.2% Metropolis Intercom S.A. AS8010 120 38 82 68.3% PublicNet Communications, Inc. AS4755 216 136 80 37.0% Videsh Sanchar Nigam Ltd. Autonom AS1239 486 407 79 16.3% Sprint AS2048 182 106 76 41.8% State of Louisiana AS12302 109 33 76 69.7% MobiFon S.A. AS724 231 166 65 28.1% DLA Systems Automation Center AS703 283 221 62 21.9% UUNET Technologies, Inc. AS3464 155 97 58 37.4% Alabama SuperComputer Network AS16758 63 6 57 90.5% IKON Office Solutions AS3908 321 265 56 17.4% Supernet, Inc. AS13999 70 14 56 80.0% Mega Cable S.A. de C.V. AS6471 121 66 55 45.5% ENTEL CHILE S.A. AS19834 63 8 55 87.3% NetForce, Inc. AS1 509 454 55 10.8% BBN Planet AS4323 366 312 54 14.8% Time Warner Communications, Inc. AS2149 323 270 53 16.4% Performance Systems, Inc. AS4200 103 51 52 50.5% Apex Global Information Services, AS209 297 246 51 17.2% Qwest 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

microsoft
by Ian A Finlay 28 Dec '01

28 Dec '01

Can anyone shed light here? iaf@duwo/iaf 148=>nslookup Default Server: duwo.pair.com Address: 209.68.2.64 > windowsupdate.microsoft.com Server: duwo.pair.com Address: 209.68.2.64 *** duwo.pair.com can't find windowsupdate.microsoft.com: Non-existent host/domain I'm seeing this from several different places on the Internet. Also, the TTLs were very short a little bit ago: $ dig windowsupdate.microsoft.com ; <<>> DiG 8.3 <<>> windowsupdate.microsoft.com ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; windowsupdate.microsoft.com, type = A, class = IN ;; ANSWER SECTION: windowsupdate.microsoft.com. 30S IN A 207.46.226.17 ;; Total query time: 76 msec ;; FROM: holmes.blue.cert.org to SERVER: default -- 192.88.209.153 ;; WHEN: Fri Dec 28 11:32:11 2001 ;; MSG SIZE sent: 45 rcvd: 88 -Ian

2 2