- NANOG - lists.nanog.org

What happened to dot pro ?
by John R Levine 02 Feb '04

02 Feb '04

One of the new domains set up in 2002 was .pro, with three initial subdomains .med.pro, .law.pro, and .cpa.pro. They'd register applicants only after checking evidence that they're licensed in the appropriate profession. (Applicant sends state and license number, registry looks them up to be sure the name matches.) With the growing epidemic of phishing, it would be handy to know that mail from, say, deloitte.cpa.pro was really from my accountant and not from some phisher who'd registered a similar looking .com. They had a sunrise period in early 2003 so big firms could pre-squat on their famous names and trademarks, and it was supposed to go live in July. The registrar's site at registrypro.com is up, but shows no evidence of having been touched since about May, and I can't find anything else since May either. Anyeone know what happened to them? I know a couple of CPAs and lawyers who could use a hard-to-spoof domain name. Regards, John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner "I dropped the toothpaste", said Tom, crestfallenly.

1 0

RE: Did Wanadoo, French ISP, block access to SCO?
by CHUNIKHIN Igor FTLD 02 Feb '04

02 Feb '04

Did go through last time: -----Original Message----- From: CHUNIKHIN Igor FTLD Sent: Sun 2/1/2004 6:18 PM To: 'hackerwacker(a)cybermesa.com'; Sean Donelan Cc: nanog(a)merit.edu Subject: RE: Did Wanadoo, French ISP, block access to SCO? Let me clarify: 1) Wanadoo is French domestic network, while Opentransit is international backbone. 2) Opentransit (AS 5511) didn't block www.sco.com. Your traceroute goes via Opentransit but dies on peering point with XO; it looks like they killed this host. Cheers, Igor Chunikhin Engineering Support Lead Engineer FTLD IPTAC +1 703 375 6154 (office) > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > James Edwards > Sent: Sunday, February 01, 2004 4:21 PM > To: Sean Donelan > Cc: nanog(a)merit.edu > Subject: Re: Did Wanadoo, French ISP, block access to SCO? > > > Here is a view from the west coast, This is via > Opentransit, which is my limited understanding of French > indicates is owned/part of FranceTelecom: > > trace 216.250.128.12 > > Type escape sequence to abort. > Tracing the route to www.sco.com (216.250.128.12) > > 1 P12-0.PALBB2.Palo-alto.opentransit.net (193.251.240.26) 0 msec 0 > msec 0 msec > 2 * * > p5-0.IR1.PaloAlto-CA.us.xo.net (207.88.250.29) [AS 2828] !H > > >From Pastourelle, via Opentransit: > > trace 216.250.128.12 > > Type escape sequence to abort. > Tracing the route to www.sco.com (216.250.128.12) > > 1 P12-0.NYKCR3.New-york.opentransit.net (193.251.241.134) 144 msec 216 > msec 212 msec > 2 P7-0.NYKBB3.New-york.opentransit.net (193.251.241.242) 76 msec 76 msec > 76 msec > 3 * * * > > > >

1 0

Re: Impending (mydoom) DOS attack
by E.B. Dreger 02 Feb '04

02 Feb '04

PG> Date: Sat, 31 Jan 2004 17:04:32 +1100 (EST) PG> From: Phillip Grasso PG> I've implemented a means of distributing the www.sco.com/32 PG> or any other DDoS destination network block around my own PG> AS and blocking it by routing to null on the edge routers. Consider also: Martini tunnels IIRC, a recent NANOG presentation explained this in greater detail. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist(a)brics.com -or- alfra(a)intc.net -or- curbjmp(a)intc.net Sending mail to spambait addresses is a great way to get blocked.

1 0

RE: Verizon mail troubles
by Alon Tirosh 01 Feb '04

01 Feb '04

Personal Favorite: We put a move order in with VZ for June 12, then rescheduled to July 12 (we were moving across the st.) of this year. On May 12 we come in and discover that half our lines don't work. After 4 hours on the phone, it turns out they took exactly half our lines (interestingly enough 1,3,5,7,etc.) and moved them across the street, and wired them into the phone block for what was to be our neighbouring office. People calling us got a furniture consulting firm half the time. It took me 5 days to get all our lines back where they belonged, as when they moved them back they decided to leave a couple there and then not acknowledge the problem, only to move again finally in July and have them forget to move a couple lines over. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Gerald Sent: Thursday, January 29, 2004 3:03 PM To: Brian Wallingford Cc: Andy Dills; Bob Snyder; nanog(a)merit.edu Subject: Re: Verizon mail troubles On Wed, 28 Jan 2004, Brian Wallingford wrote: > There's no question that there's a certain amount of social > engineering involved in contacting (or being allowed to contact) > competent folk. It's advisable to be sure that any staff who will be > contacting them are fully versed in any services they will be > discussing. The clueful staff at VZ are much more receptive and > accessible when they know in advance that they can expect to pick up a likewise-clued individual. My favorite (extreme sarcasm) lines I received from Verizon: - (At 25 Bway with a T3 from the carrier room.) "The T3 outage you are experiencing is not our problem." Turned out someone messed up a cable in to their router in the carrier room. A tech that they dispatched to 25 Bway got access to the carrier room and recrimped the cables in to THEIR equipment, not ours. Anyone who knows 25Bway knows you can't enter the carrier room without a purpose. I can't go there and say let me work on VZ equipment in the Carrier room. - "I don't see the circuit ID for the T3 you just gave me in here do you have another CID for it?" - Random person in back office I had been transferred to, "(definitively) It's not a problem on our system...What was that CID again? Let me trace each leg of the Circuit. (pause) Oh wait, there is a problem in the Central Office that that would affect that line" Me, "How do I keep up with the progress of this ticket? Is there a ticket number on that problem?" Him, "It's an internal ticket number. I can't give it out." - "If you are having intermittent problems, we can't do anything about it. We can test the line and if the T1 shows clean we will close the ticket." - Me, "The T1 CID $CID is down." Them, "What would you like us to do?" - (From a T1 plagued with issues after 9/11. Paraphrased:) "Due to the wiring in your building it would probably be best if we just ran a new T1 out to you. You will need to sign a new 60 month contract and we will work out the details of closing the old T1 once the new one is setup." (This was a sales rep.) - "Hi, I'm Chris L. I'm your new account manager. I will be your contact with any problems you have." (Chris no longer answers his phone. Neither does anyone else from the "Enterprise Services" dept here in NYC. None of the phone numbers Chris sent to me respond either.) - The Trouble ticket line has given up any semblance of desire to help Most companies answer "$Company_Name, This is $Name speaking, how may I help you?" The TT line, "Verizon?!" - T1 group, "I can loop the smart jack." Me on site, "The smart jack has no lights." Them, "Oh, wait I was looping the wrong smart jack, what was that CID again?" - My favorite recording from the trouble ticket line: "We are experiencing an unusually high call volume, please try your call again later <CLICK>" - One T1 outage last year: T1 tech says need to dispatch to site, Site tech says no issue at smart jack need to get basement people in here (don't remember the name right off), basement people say we can't hear anything from C.O., C.O. tech says we can't hear anything from the building. This outage took 5 days to recover from to get techs on site and dispatched after each person pointed the finger at another person. I could go on, but it is just depressing. I still have no one to complain to if I can't get a hold of my sales rep or the T1 TT line screws up royally.

3 2

www.sco.com no longer has an DNS A record
by Sean Donelan 01 Feb '04

01 Feb '04

Asia (remember the international date line) started on MyDoom already, although some reports said the worm used 1609 GMT to start its attack. SCO appears to have deleted the A record for www.sco.com from their DNS about 1 hour ago. I don't know how often MyDoom does the DNS lookup, so it may not stop things. As far as I can tell, no third-party ISP is blocking traffic to SCO. Traceroutes by IP address continue to nearly their last upstream hop. SCO's immediate upstream providers are probably helping.

6 6

Impending (mydoom) DOS attack
by bcm 01 Feb '04

01 Feb '04

Is anyone taking any special precautions given the potential for a sudden increase in aggregate packets per second across your networks come Sunday afternoon when the original Mydoom virus enters into its DOS phase? Does anyone know if the virus' assault will be slowed if it is unable to reach www.sco.com? I am hoping that if it cannot reach SCO's site that the HTTP GET command will be slow in returning, effectively reducing the volume of traffic a single PC is capable is generating. I am having a difficult time artificially forcing the virus to start its attack in a lab environment, so I am unable to confirm this. Any input would be appreciated. Thanks!

10 14

Re: [Full-Disclosure] Mydoom DDoS attack time table
by James Edwards 31 Jan '04

31 Jan '04

On Sat, 2004-01-31 at 08:27, Gadi Evron wrote: > I apologize if in my previous email I didn't make it clear, this is an > important issue for system administrators world wide, so I am emailing > again in regard to this subject alone - a time table for the Mydoom DDoS > attack. > > In my post from the 30th of January with the subject: "Refuting > tall-tales and stories about the Mydoom.A and Mydoom.B worms" - > we released an analysis of the Mydoom worms DoS mechanism, refuting > rumors about it not existing (http://www.math.org.il/mydoom-facts.txt) > > You can find a _time_table _for when the DDoS attack will happen, as > calculated by a C program Joe Stewart wrote at: > http://www.math.org.il/mydoom-a-timeline.txt > > Mydoom.B has a time line too, but it can't be predicted as definitely > because of an extra random check. > > For more information about the DoS attack itself performed by the worm, > how and when (including reverse engineering bits) you should check the > above mentioned article. > > Gadi Evron. > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html

1 0

reminder ipv4 allocation 83/8 (IANA to RIPE-NCC)
by Christian Steger 31 Jan '04

31 Jan '04

hello there, i just want to remind you, that IANA has allocated an new block in november 2003 (83/8). the reason why i remind again here is, we (as8514) have received a block within that range (83.64/15 --> RIPE-NCC) in the end of 2003 and customers complains still sites in the state they can´t reach. i kindly ask you to modifiy the BOGON list. thanks! christian steger -- Christian Steger | R & D: Network Fon. 059 999 0 | Inode GmbH, Backbone Austria Fax. 059 999 6699 | Interxion, Shuttleworth Strasse 4-8, 1210 Wien www.inode.at | Raserei verbindet uns.

2 1

RE: CIsco 7206VXR w/NPE-G1 Question
by Michel Py 31 Jan '04

31 Jan '04

> Richard J. Sears wrote: > I am looking at upgrading my current 7507 backbone routers. > Each of my routers has dual RSP4s Keep in mind that dual RSP does _not_ mean load sharing; it's for redundancy, if you can get RPR+ to work the way you want that is. > and I was thinking of upgrading them to RSP8s when I > started reading about the new 7206VXRs with the NPE-G1 engine. > I was wondering if anyone has had experience with this > router/engine combination, how well they perform in comparison > to the RSP8s and actual total traffic capabilities when > utilizing all three gig ports with a mixture of OC3, Gig and > DS3 connections as well. In my experience, no 7507 is capable of this, nor a 7206VXR. As pointed out not too long ago, the RSP8 although intrinsically slower than a NPE-G1 will take more load because a lot of processing can be done by the VIPs in the 7507. The deal is that in a 7200 the NPE does the work of the RSP _plus_ the work of three VIPs; even if it's faster, it might not be that fast. That being said, I don't consider reasonable to get gig+ traffic trough a 7507; in my experience a 7500 will push 500mbps of traffic but will have trouble swallowing a full gig. My limited experience with the 7206 says that it might eventually be able to push _one_ gig from one PA to another, but not aggregate: say you have 4 or 5 OC3s aggregating into a GigE with some ACLs (which would run distributed on a 7500) I don't think that even the NPE-G1 is up to the task. IMHO, if you stay well below a gig, these el-cheapo eBay RSP8 deals are a valid solution but if you go over, GSR or Juniper is your answer. The 7200 has never been a core nor backbone router. Michel.

4 5

RE: CIsco 7206VXR w/NPE-G1 Question
by sthaug＠nethelp.no 31 Jan '04

31 Jan '04

> > PXF is found in the 7400 (old) and 7300 (newer) series. > > Not true. 7401 has a PXF. It's essentially an NSE-1 with GE/IO in a > pizza box. 7301 is based on the NPE-G1 and doesn't have a PXF anywhere > in sight. On the other hand, the (original) 7304 used PXFs, on the NSE-100 forwarding engine. Cisco later introduced the NPE-G100 for the 7304 with a much more powerful CPU, but no PXF. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0