January 2003 - Test - lists.nanog.org

The Cidr Report
by cidr-report＠potaroo.net 31 Jan '03

31 Jan '03

This report has been generated at Fri Jan 31 21:45:39 2003 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 24-01-03 118201 85103 25-01-03 118189 83778 26-01-03 116341 84709 27-01-03 117892 84848 28-01-03 118004 85138 29-01-03 118290 85119 30-01-03 118378 85040 31-01-03 118463 85056 AS Summary 14479 Number of ASes in routing system 5680 Number of ASes announcing only one prefix 1585 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73080832 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 31Jan03 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 118597 85097 33500 28.2% All ASes AS3908 1179 682 497 42.2% SUPERNETASBLK SuperNet, Inc. AS18566 450 7 443 98.4% COVAD Covad Communications AS701 1585 1174 411 25.9% ALTERNET-AS UUNET Technologies, Inc. AS7018 1427 1035 392 27.5% ATT-INTERNET4 AT&T WorldNet Services AS4323 527 170 357 67.7% TW-COMM Time Warner Communications, Inc. AS7843 584 257 327 56.0% ADELPHIA-AS Adelphia Corp. AS6197 471 154 317 67.3% BATI-ATL BellSouth Network Solutions, Inc AS1221 1136 830 306 26.9% ASN-TELSTRA Telstra Pty Ltd AS6347 376 85 291 77.4% DIAMOND SAVVIS Communications Corporation AS4355 410 126 284 69.3% ERMS-EARTHLNK EARTHLINK, INC AS1239 958 675 283 29.5% SPRINTLINK Sprint AS22927 295 14 281 95.3% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS7046 551 277 274 49.7% UUNET-CUSTOMER UUNET Technologies, Inc. AS4151 329 58 271 82.4% USDA-1 USDA AS4814 261 15 246 94.3% CHINANET-BEIJING-AP China Telecom (Group) AS705 435 190 245 56.3% ASN-ALTERNET UUNET Technologies, Inc. AS852 680 445 235 34.6% ASN852 Telus Advanced Communications AS1 663 435 228 34.4% GNTY-1 Genuity AS6198 424 202 222 52.4% BATI-MIA BellSouth Network Solutions, Inc AS22291 237 30 207 87.3% CHARTER-LA Charter Communications AS17676 220 24 196 89.1% GIGAINFRA XTAGE CORPORATION AS690 505 311 194 38.4% MERIT-AS-27 Merit Network Inc. AS209 521 333 188 36.1% ASN-QWEST Qwest AS4134 301 117 184 61.1% ERX-CHINALINK Data Communications Bureau AS2386 435 258 177 40.7% INS-AS AT&T Data Communications Services AS6140 306 132 174 56.9% IMPSAT-USA ImpSat AS2048 259 87 172 66.4% LANET-1 State of Louisiana AS6327 187 36 151 80.7% SHAWFIBER Shaw Fiberlink Limited AS17557 330 183 147 44.5% PKTELECOM-AS-AP Pakistan Telecom AS11492 300 157 143 47.7% CABLEONE CABLE ONE Total 16342 8499 7843 48.0% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

Banc of America Article
by Alex Rubenstein 30 Jan '03

30 Jan '03

http://biz.yahoo.com/rb/030125/tech_virus_boa_1.html Let's make the assumption that the outage of ATM's that BoA suffered was caused by last nights 'SQL Slammer' virus. The following things can then be assumed: a) BoA's network has Microsoft SQL Servers on them. b) BoA has not applied SP3 (available for a week) or the patch for this particular problem (SQL Slammer) (available for many months). c) somehow, this attack spawned on the public internet made it's way to BoA's SQL servers, bypassing firewalls (did they have firewalls?). Another article states, "Bank of America Corp., one of the nation's largest banks, said many customers could not withdraw money from its 13,000 ATM machines because of technical problems caused by the attack. A spokeswoman, Lisa Gagnon, said the bank restored service to nearly all ATMs by late Saturday afternoon and that customers' money and personal information had not been at risk." Does anyone else, based upon the assumptions above, believe this statement to be patently incorrect (specifically, the part about 'personal information had not been at risk.') ? I find these statement made by BoA, based upon assumptions which are probably correct, to be very scary. Comments? -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

14 17

RE: .org whois - a clarification
by Bruce Beckwith 30 Jan '03

30 Jan '03

Please note that this is an issue that ICANN is addressing. PIR is working with the staff at ICANN to assist in any way necessary. Regards, Bruce Beckwith Public Interest Registry ) There has been some confusion about the naming of the new .org whois for ) port 43 service. As noted now on our web site, and also in other posts, ) it can be found at: ) ) whois.publicinterestregistry.net Will rs.internic.net eventually provide referals to the appropriate whois servers, or will there be a "smarter" referer somewhere along the lines?

1 0

FW: .org whois - a clarification
by Bruce Beckwith 30 Jan '03

30 Jan '03

The following comment was made privately, yet since it may be of interest to others, I am posting the question and noting that we have gone ahead and done this. Regards, Bruce Beckwith Public Interest Registry >There has been some confusion about the naming of the new .org whois for >port 43 service. As noted now on our web site, and also in other posts, >it can be found at: > >whois.publicinterestregistry.net why not also whois.pir.org for those of us who actually type this stuff on command lines? Any chance of a CNAME? Sure would be nice.

1 0

Re: OT: Banc of America Article
by Mike Hogsett 30 Jan '03

30 Jan '03

> Before you jump to the conclusion that you could just steal the black > box from the ATM and have access, but if you till it, it forgets all the > keys. Also during normal operation two separate people have to enter > two parts of the key. This way no single bank employee has access to > both parts of the key. The product Krzystof mentions is likely similar to : http://gpsonsale.com/ibmcryptographiccards/products/IBM4758-002.htm http://www-3.ibm.com/security/cryptocards/ An interesting read regarding breaking into one of these black boxes : http://www.cl.cam.ac.uk/~rnc1/descrack/ - Mike

1 0

.org whois - a clarification
by Bruce Beckwith 30 Jan '03

30 Jan '03

There has been some confusion about the naming of the new .org whois for port 43 service. As noted now on our web site, and also in other posts, it can be found at: whois.publicinterestregistry.net In addition, you will find a web-based whois at: http://www.pir.org/whois/ There have also been questions regarding the output for whois. Keep in mind that PIR has transitioned the .org data from the former "thin" registry which was using RRP. Though PIR supports RRP commands which are translated into EPP commands automatically, by December 2003, PIR will have an EPP implementation with "thick" data in place for all registrars. Registrars will be migrated individually throughout the year. The format of the whois output was designed to be remain consistent through this migration. Regards, Bruce Beckwith Public Interest Registry http://www.pir.org

1 0

RE: OT: Banc of America Article
by Temkin, David 30 Jan '03

30 Jan '03

FYI this is completely incorrect. I have changed my PIN with both my PayPal debit card as well as my First Union/Wachovia card numerous times without a single contact with a physical bank. See: http://www.wachovia.com/helpcenter/page/0,,2372_2705,00.html To store the PIN on a card, whether hashed or not, would be foolish. Do people really think that the ATM's of 15 years ago had the CPU power to calculate the hash of a PIN number on the fly? I know people who are carrying around 10+ year old cards and they still work fine. -Dave > -----Original Message----- > From: Krzysztof Adamski [mailto:k@adamski.org] > Sent: Thursday, January 30, 2003 3:39 PM > To: nanog(a)merit.edu > Subject: Re: OT: Banc of America Article > > > > Since nobody has given the correct information about the PIN > on the card I will give a very brief description. > > There are two types of PIN, natural and customer selected. > The natural PIN is computed from the number on the card. The > computation involves one way crypto keys. I don't remember > the algorithm. For this the PIN that is stored on the card is 0000. > > Now, when a customer selects a PIN, an offset is computed > between the natural PIN and selected PIN. This offset is > stored on the card. > > Based on this you can see that re-encoding is needed when you > change the PIN number, most ATM will do that re-encoding. So > unless things have changed in the last 4 years since I worked > with this, you can not change your PIN over the phone without > physical contact by the bank with the card. > > Personally I carry a card without any logo as my ATM card, at > one point I had access to reader/encoder for mag strip cards > and I programmed a blank card with the info from my real ATM > card. No encryption involved. > > K > > On Wed, 29 Jan 2003, David Charlap wrote: > > > > > Al Rowland wrote: > > > > > > The PIN is on your card ... > > > > Not for any card I've ever owned. I've changed my PIN several times > > over the years, and the bank has never re-encoded my card > or sent me a > > new card as a result of doing so. > > > > Maybe some banks do store the PIN on the card, but I'm certain that > > it's > > in the server for ever bank I've used. > > > > > I use a not-my-bank ATM in the lobby at work and it > doesn't initiate > > > the call (you can hear the modem dial) until you're > beyond the PIN > > > screen and are actually requesting a transaction. > > > > I'm not surprised. But the PIN is verified as a part of the > > transaction. > > > > I've occasionally mistyped my PIN. The ATM takes the > mistake and goes > > straight to the menu. It's only after requesting a > transaction that it > > comes back with the "invalid PIN" message. > > > > -- David > > > IMPORTANT:The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

Re: routing between provider edge and CPE routers
by Miquel van Smoorenburg 30 Jan '03

30 Jan '03

In article <cistron.7CD4CD9D537C294D9ED9E5CE2F019106B6BC4D(a)MAILSERV.linc2icn.net>, Mike Bernico <mbernico(a)illinois.net> wrote: >> So, by accepting routes from CPE you create a huge security >vulnerability >> for your customers, and other parties. This practice was understood >as a >> very bad network engineering for decades. > >Is there someplace I can find tidbits of information like this? I >haven't been alive decades so I must have missed that memo. Other than >this list I don't know where to find anyone with lots of experience >working for a service provider. You could have thought this up yourself. If you put something in production, /always/ ask yourself: if I was a hacker with bad intentions, how could I abuse this. And actually try to. I hacked my own network and machines a couple of times for fun, you learn a lot from it. Mike. -- Anyone who is capable of getting themselves made President should on no account be allowed to do the job -- Douglas Adams.

1 0

Re: Bell Labs or Microsoft security?
by Simon Waters 30 Jan '03

30 Jan '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: "E.B. Dreger" <eddy+public+spam(a)noc.everquick.net> > > ML> No, it isn't, as is doing buf_t[x] rather than pointer > > True. I just like having a struct so I may pass a single > variable in function calls instead of a whole mess of them. The problem is not pointers, it is pointers pointing at things that don't belong to them or that they don't understand. > Is it unreasonable to ask that programmers not assume memory is > initialized, to check bounds as needed, and to realize that > operations are NOT atomic without special protection[*]? 40 years of experience says it is unreasonable to expect the programmer to get it right 100% of the time. A modern server or Desktop OS is measured in hundreds of millions of lines of code, what is an acceptable error rate per line of code? Last time I looked the average C programmer was running at about 1 "error" every 10 lines. Errors of this specific type in mature code probably running a lot less, but we are probably talking about ~100,000's of such issues in a typical Unix box. - From a NANOG perspective it only really matters if they are in a network service, but from a cracking perspective any program you can feed, or get the user to feed corrupted input into will do fine. > I don't think so. Be assured it is. Programmers even the best make mistakes. > Sure, it's extra work; put it in a library. Precisely, most advocating change want an automated system, ideally something that lets us use all the many millions of lines of existing C code without too much aggrevation or performance hit. Most people here don't actually care "that" much if a specific program operates 100% correctly, only if it is subverted by worms or crackers to affect the integrity of the host system and/or network - in which case something like StackGuard is appropriate. However fixes like StackGuard don't really remove the problem, they just mitigate the effects. My first experience of a big project in Java was such a relief to have a programming language where nearly all the errors either didn't compile, or were obviously and logically related to the bit that had just been altered. This is way off topic for NANOG. I guess the lesson for NANOG that it is quite easy if you have the source code to mitigate the effects of these kind of problems, such that failure to patch will result in nothing more than a DoS at worst. Although these issues have been less of a problem on systems based on free (and open source) software, although I suspect the principal(*) reason for that is diversity in architecture and compiler meaning exploiting the weaknesses is harder, even if they are there. Simon * A secondary reason could be in the e-mails from David Wheeler saying "fix this" (in the nicest possible way). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+OQ5HGFXfHI9FVgYRAgENAKC4TqEqtYO9mOzC7GUFZL0yUXxkugCfd0as cV4IA/+PHmi26hGwzPwWP5M= =DJjK -----END PGP SIGNATURE-----

3 2

Re: Bell Labs or Microsoft security?
by Michael.Dillon＠radianz.com 30 Jan '03

30 Jan '03

> PS: Worm? Virus? Who wrote this up concisely first? Shockwave Rider by John Brunner Is it still in print, I wonder? --Michael Dillon

2 1