- NANOG - lists.nanog.org

Agenda redux
by Susan Harris 18 Jan '05

18 Jan '05

Many thanks to Chris Malayter, who's kindly volunteered to moderate our IXP panel in Las Vegas. The General Session will now run until ~1:00 p.m. Tuesday afternoon, and Chris will be sending a message to the list shortly.

1 0

XO Outage in Chicago?
by Joseph Johnson 18 Jan '05

18 Jan '05

Anyone see an outage at XO in Chicago? From Alter.net, Verio, and Level 3 I die at the crossover point to XO at the Chicago Exchange. Thanks! Joe Johnson

2 1

RE: Panix.com should be back.
by Hannigan, Martin 18 Jan '05

18 Jan '05

And to think I went to college. Even. Folks, 'Blackberry Gone Wild'. Usually a great device, but tremendously beat and now showing it. That should simply read 'Thanks Farid'. The thing went wild storing keystrokes like it was hung, autocompleting, and sending everywhere. Twice here and to many people on in the addr book privately. Mea Culpa. -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan(a)verisign.com > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Hannigan, Martin > Sent: Sunday, January 16, 2005 11:01 PM > To: MajidFarid(a)TelecomOttawa.com; nanog(a)merit.edu > Subject: Re: Panix.com should be back. > > > > > > Thanks Fared for your assistance. Ypu are great among a bun > --- > Martin Hannigan > hannigan(a)verisign.com > Verisign, Inc. > > > -----Original Message----- > From: owner-nanog(a)merit.edu <owner-nanog(a)merit.edu> > To: nanog list <nanog(a)merit.edu> > Sent: Sun Jan 16 19:57:54 2005 > Subject: Panix.com should be back. > > > I see that DNS changes has been reverted > http://www.dnsreport.com/tools/dnsreport.ch?domain=panix.com > > I have also contacted our Customer owner of ns1.ukdnsservers.co.uk > [panix.com] (142.46.200.67) they have assured me they will remove the > DNS config as well. > > > Sorry for the last response I was away for weekend. > > -- > Majid Farid > Telecom Ottawa Limited. > > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of > Gadi Evron > Sent: Sunday, January 16, 2005 7:24 PM > To: nanog list > Subject: domain hijacking - what do you do to prepared? > > > Until today, I considered this to be a real and relevant threat, > although rather low in my matrix. > > As someone I know said today, now that kiddies saw how much > "fun" this > is, I am sure they will attempt this again. > > The question that comes to mind is - what do you do to be prepared? > > I suppose that other than setting registrar lock in place, there is > another thing one can do. > > Study! > > Whether it's checking the expiration date for your domain, > establishing > contact with your up-in-line authority - registrar, tld, etc. > depending > on who you are. > Having the relevant contact information at hand, establishing a set > policy on how to handle such an incident and who to contact, bugging > your next-in-chain about setting a policy on this with you, > as well as > setting such a policy for those who are slaves to you. > > That said, all that is left now is to see how this happened > (so that it > won't happen again - just killing a fire doesn't mean it won't be > re-ignited) and perhaps think a bit on how we do things - which I am > sure many will now do. > > Maybe this can be another discussion issue for the next NANOG > get-together as well? > > Gadi. >

1 0

RE: netblazer Was: baiting
by Hannigan, Martin 18 Jan '05

18 Jan '05

> -----Original Message----- > From: Robert E.Seastrom [mailto:rs@seastrom.com] > Sent: Tuesday, January 18, 2005 11:11 AM > To: Eric Brunner-Williams in Portland Maine > Cc: Hannigan, Martin; wsimpson(a)greendragon.com; nanog(a)merit.edu > Subject: Re: netblazer Was: baiting > > > > Eric Brunner-Williams in Portland Maine <brunner(a)nic-naa.net> writes: > > > In this period of time, the White Knights built the InterOp > shownets and > > we had comparative access to quite a lot of vendor product, > and know that > > the red buttons on Wellfleets were correctly positioned on > the front, for > > easy access. We used NetBlazers for dial-up outbound (we > were topologically > > quite diverse by '91, our last show in the San Jose > facility) and I don't > > recall anything ... resembling the behavior that I could > characterize as > > POS like function. > > My recollection of that show was "T-1 to BARRnet", not > bonded-Netblazer-dialout, but I didn't "work the show" until the > following spring, so my recollection could be at fault. > > I wouldn't characterize Netblazers as being particularly cruddy > compared to other options available at the time. Remember that this > was the era of the Cisco ASM, the Encore/Xylogics Annex (Wellfleet > hadn't changed their name to Bay yet, much less bought the Annex > product line), some nasty 3com terminal server of which my memory has > thankfully purged most details and the gone but not lamented Cisco > TRouter. The Netblazers worked pretty darned well when plugged into > Telebit modems. Third party modems, well, there were a lot of knobs > you could twist, and not the best in the way of documentation on what > to do with 'em. > > Based on my experience with them, I'm quite sure they were fabulous > devices capable of being configured in the field to do just about > anything, if you had the level of familiarity with their internals > that someone who worked QA for them would have had. There really wasn't any good modem, IMHO, back then. They were all painful to configure and make work reliably. Once the "net" revolution started it still took years to get modems working reliably. In '98 I know that the Max TNT was only getting about 85% call completion across_the_board. Call completion only takes into account the completed handshake. Then you dealt with code issues after you got them to at least connect. -M<

1 0

IETF Administrative Director Job Announcement
by Kurt Erik Lindqvist 18 Jan '05

18 Jan '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Internet Engineering Task Force (IETF) is responsible for developing and defining the standards and protocols that make up the Internet. The IETF was established in 1986, and has since then been the center of development for the technologies that make up what we think of as the Internet. Until now, administration of the IETF has been carried out by helper organizations; the IETF has had no direct staff that was working only for the IETF and its interests. The community that makes up the IETF has as part of a long-term administrative restructuring, decided to create an Administrative Support Activity, the Internet Administrative Support Activity (IASA). The IASA will formally be structured as a function of the Internet Society (ISOC). To run this activity, the IASA Transition Team is now seeking a highly capable individual to serve as IASA Administrative Director (IAD). The IAD will lead the work of supporting the organization that defines and develops the future Internet and associated technologies. As IAD, you will be reporting to the IETF Administrative Oversight Committee (IAOC) and be accountable to the IETF community. This is a highly visible and very demanding job; you will be expected to work daily with some of the leading Internet technologists of the world. You will be expected to: o Document the administrative requirements of the IETF, IESG, IAB and IRTF, and manage the work to fulfill them. o Establish the IASA annual budget, oversee financial administration, and report on IASA work to the IETF. o Work with ISOC and various service providers to establish appropriate agreed budgets and related financial and performance reporting. o Negotiate contracts with service providers and establish procedures for measuring and reporting the performance of these providers. o Serve as the day-to-day responsible person for administrative operations that support the IETF process, managing a number of contractors and working with a number of volunteers. o Serve as the primary staff resource for the IASA. o Work with your contractors and members of the IETF community to provide adequate support and planning for 3 IETF meetings annually, and for frequent meetings and teleconferences of the IAB, IESG, and other bodies that support the IETF. The following characteristics are necessary for this job: o This job is public service. You should be able to work successfully with large numbers of people from numerous countries. This requires a large work capacity, the ability to handle many simultaneous tasks, and the ability to listen carefully. o This is an operations job. IETF meetings are large and complex, and the day-to-day activities of the standards-making process is demanding. You should be adept at getting real results and helping large groups work together towards common goals and deadlines. o This is a public job. You will be required to present the results and achievements of the IASA in front of the community as well as dealing with questions from individual members of the community. One goal of IASA is to achieve as much transparency and accountability as possible, so good communication skills and previous similar experiences are valued. o This job requires a financially astute individual. The IETF is a $2-$3 million per year operation. IETF funds are tight and we expect you to take leadership in establishing our budgetary procedures, our procurement standards, and understanding our revenue sources. In-depth familiarity with the IETF prior to assuming this position is not required, but you must be able to get up to speed quickly and learn the unique culture and requirements of the organization. Likewise, long-term technical experience is not required, but you must be a quick learner and adept at using the Internet effectively. The person hired will be an employee of the Internet Society (ISOC). The Internet Society is based in Reston, Virginia and in Geneva, Switzerland, and the job will require a high level of travel for IETF meetings and preparation and related meetings. You may work out of a home office as a telecommuter or use the Internet Society facilities. In either case, you should be prepared to travel frequently to Virginia, IETF meetings, and the locations where the IETF has contractors. Salary levels commensurate with experience and qualifications. You must be fluent in spoken and written English. Applications should have a covering letter and include a CV. They can either be sent to iad2005(a)isoc.org, or an applicant can fill in the application form at https://www.isoc.org/isoc/general/career/jobapplication.php. For any questions, please contact iad2005(a)isoc.org. Applications will be evaluated starting February 18th, and continuously thereafter. Applications will be evaluated, and the IAD will be selected and appointed, by the IASA transition team. The list of applicants will not be posted publicly, but will be reviewed in confidence by members of the evaluation committee, the IAB, and the IESG. -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQe0026arNKXTPFCVEQKKoQCgrlm/kg2tbiC4kwWas3Y6U2cTNUgAn2EZ KnA5b45M7WiC8pp7JH2vTY4N =pJQ6 -----END PGP SIGNATURE-----

1 0

Draft agenda for Las Vegas
by Susan Harris 18 Jan '05

18 Jan '05

This is *really* late notice, but we are looking for someone who might be willing to moderate an IXP panel, which would be held Tuesday, Feb. 1. If you're interested, please contact nanog-support(a)nanog.org, and see you all soon! --------------------------------------------------------------------------- NANOG 33 Draft Agenda January 30 - February 1, 2005 Las Vegas, Nevada Sunday Tutorials --------------- 1:30 - 3:00 p.m. BGP Multihoming Techniques Level: Introductory Philip Smith, Cisco 1:30 . 3:00 p.m. Build for Success - How to Use Network Design Principles to Differentiate the Good, the Bad, and the Ugly Level: Introductory/Intermediate Barry Greene and Dave Meyer, Cisco 3:00 - 3:30 p.m. BREAK 3:30 - 5:00 p.m. BGP Multihoming Techniques (cont'd.) 3:30 - 5:00 p.m. Understanding MPLS OAM Capabilities for Troubleshooting MPLS Networks Level: Intermediate Moiz Moizuddin and Mukhtiar Shaikh, Cisco 5:00 - 7:30 p.m. Dinner Break 7:30 - 9:30 p.m. Coordinating NANOG: Input From the Community Betty Burke, Merit Steve Feldman, CNET Martin Hannigan, VeriSign Paul Vixie, ISC Monday, January 31 - General Session ------------------------------------ 9:00 a.m. Welcome, Introductions Susan Harris, Merit; Rodney Joffe, UltraDNS 9:15 a.m. A Day in the Security Life of a Service Provider - Qwest Don Smith, Qwest 9:45 a.m. Team Cymru Bogon Route Servers Dave Deitrich, Team Cymru 10:15 a.m. BREAK 10:45 a.m. Open Source IDS Acceleration by Flow Reduction Paul Tatarsky, UCSC 11:15 a.m. Panel: BGP Security Requirements.An Overview of Current Work in the IETF Russ White, Cisco, moderator; Danny McPherson, Arbor Alvero Retana, Cisco; Blaine Christian, MCI 12:00 p.m. LUNCH (on your own) 1:30 p.m. Looking Glasses - What's In It for You? Steve Gibbard, Packet Clearing House 2:00 p.m. IP Fast Reroute: Overview and Things We Are Struggling to Solve Dave Ward, Cisco 2:30 p.m. IP Fast-Reroute: An Analysis of Applicability to a Core Network Alia Atlas, Avici; Gagan Choudhury, AT&T 3:15 p.m. BREAK 3:45 p.m. Implementation of Modern L2 VPNs Scott Gross, MCI 4:15 - Panel: Network-based Layer 2/3 VPN Deployment Considerations 5:15 p.m. Danny McPherson, Arbor, moderator; Ted Seely, Sprint Shane Amante, Level(3); Shankar Rao, Qwest 5:30 - 7:30 p.m. Beer 'n Gear! Monday Evening BOFs & Key Signing --------------------------------- 7:30 - 9:00 p.m. ISP Security and NSP-SEC BOF VII Danny McPherson, Arbor, moderator 9:00 p.m. PGP Key Signing Party Majdi Abbas, Lattice Networks, host 9:00 - 10:30 p.m. Peering BOF VIII William B. Norton, Equinix, moderator Tuesday, October 19 - General Session ------------------------------------- 9:00 a.m. IGP Tuning in an MPLS Network Martin Horneffer, Deutsche Telekom 9:30 a.m. Experience With In-bailiwick Nameservers Masato Minda, JPRS 10:00 a.m. IETF Update Leslie Daigle, VeriSign; Alex Zinin, Alcatel 10:30 a.m. BREAK 11:00 a.m. A Look at the IP Multimedia Subsystem Dave Meyer, Cisco 11:30 a.m. Adjourn

1 0

New Virus in the wild
by Nils Ketelsen 18 Jan '05

18 Jan '05

We see a lot of requests of the following format in our proxy logs: 1105979310.010 240001 10.3.12.211 TCP_MISS/504 1458 GET http://84.120.14.236:25204/2005/1/17/11/23/32/ - NONE/- text/html 1105979314.020 240009 10.3.12.211 TCP_MISS/504 1458 GET http://67.171.84.104:25238/2005/1/17/11/23/41/ - NONE/- text/html 1105979316.077 240068 10.3.12.211 TCP_MISS/504 1460 GET http://213.188.227.50:25401/2005/1/17/11/23/43/ - NONE/- text/html The Port these clients are trying to connect to seem to be in the range between 25000 and 26000 all the time. All requests have the timestamp in the URL (/2005/1/17/11/23/43 for example). We are currently investigating together with NAI what that is. We have a bunch of internal hosts producing these requests and the numbers are rising. The load is starting to render our proxies unusable. Any hints are very welcome. Nils

4 8

Intelsat Reports Loss of IS-804
by Fergie (Paul Ferguson) 18 Jan '05

18 Jan '05

http://www.intelsat.com/aboutus/press/release_details.aspx?year=2005&art=20… - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

1 0

Re: netblazer Was: baiting
by Hannigan, Martin 18 Jan '05

18 Jan '05

"You win. I give. Uncle." (And I was serious, not sarcastic, about the 'blazer. YMMV,) -M --- Martin Hannigan hannigan(a)verisign.com Verisign, Inc. -----Original Message----- From: owner-nanog(a)merit.edu <owner-nanog(a)merit.edu> To: North American Network Operators Group <nanog(a)merit.edu> Sent: Mon Jan 17 06:56:11 2005 Subject: Re: Association of Trustworthy Roots? [I first met Eric when I was a consultant helping put together the NetBlazer for Telebit. With my ISP hat on, we used NetBlazers for many years, very stable. I only wish that BellSouth had been as stable. We eventually switched to PortMasters for the improved diagnostics of BellSouth's continually flapping lines. However, we continued to use the old NetBlazers for internal routing up until a year or so ago. They worked well, and supported AppleTalk, too.] At Martin's insistence, and with Eric's kind permission: Eric Brunner-Williams in Portland Maine wrote: >I didn't point out to him what he already knew. That he wrote me Sunday >morning (Sun, 16 Jan 2005 07:05:42 EST), a reply off-list to my note to >Perry before going to bed around midnight. "What did I miss? Why would >they call MIT's attorney?", and that I called his cell and office about >a half-dozen times until I got him around 8am, and after 10 or so minutes >of exchanges of observations on the situation, punctuated periodically by >"I'm sure you understand there is nothing we can do", and "I don't work >on the GRS side of Verisign", I concluded with "I have a message for Chuck >Gomes, tell him that liability minimization (doing nothing until ICANN >process authorized) is the wrong choice. This is a stability of the >internet issue." > > > Seems to me that Eric worked pretty hard on this at no recompense to himself. And remember he was a voice of reason, cautioning this list to treat everyone as human beings. Martin may have finally gotten the job done, and it may have been beyond his formal job description, but I wish he'd remember to treat the rest of us as human beings, too. =------- Original Message -------- From: "Hannigan, Martin" <hannigan(a)verisign.com> Date: Mon, 17 Jan 2005 00:50:46 -0500 Why isn't this on NANOG where it started? -M PS: I used the netblazer in 93 and it was a POS. --- Martin Hannigan hannigan(a)verisign.com Verisign, Inc. =----Original Message----- From: Eric Brunner-Williams in Portland Maine <brunner(a)nic-naa.net> To: Hannigan, Martin <hannigan(a)verisign.com> Date: Sun Jan 16 16:57:52 2005 Martin, Bill and I worked together on the first demand-dialup router, the NetBlazer. That was in 1991. Scott may have a different opinion, and arguably RRP registrar/registry is semantically distinguishable from EPP registrar/registry semantics (but I wrote an I-D that contained just such a comparison to show functional equivalence), but having spent 1999 - 2003 focused on provisioning and registrar/registry semantics, I have an opinion on the correctness of the events of yesterday and today. Earlier today I wrote off-list this: Just to be formal and clear however, we had an incoherent dns, and caching resolver operators introduced the incoherency to correct for an error published by the authoritative resolver operator. As one of the EPP authors, I see provisioning and publication as two distinct functions. How state change in the registry database was provisioned -- the registrar error, is not controlling on what the registry publishes as a zonefile. VGRS erred in publication of bad data, and its error persisted for at least 12 hours, if not 24 or more, after notice. Everything else is just policy. Your milage obviously varies. VGRS's publication of the authoritative panix.com data was incorrect. Bill wrote: The domain owner and ISP and registrar all clearly stated that they had received no notification, and had not approved the transfer. I'd have used a different gramatical construct, and not distinguished between panix the registrant and panix the isp, and I've no private knowledge of Dotster's having made an affirmative response, but the registrant's claim of non-receipt of transfer is sufficient. Bill wrote: Notification and approval are required by the process. The weaker condition is simply notification, already asserted lacking by the controlling authority, the registrant. Bill wrote: Therefore, it was proven to be circumvented. QED. Xfr w/o notice is the result, but not the condition, so yes, QED. Bill wrote: Now, as to the actual mechanism of circumvention, that has not yet been revealed here. Knowlege is partial, however, unless VGRS makes the complete transactional history public, it can't make a defense that any claim is invalid based upon a claim that the knowledge is partial. Bill wrote: All we know is that a registry *supervisor* stopped the workers from finishing their investigation. I don't know how Bill knows that, but I know that I don't know the complete transactional history from VGRS, and the reason for non-disclosure of the state of the database is policy, and policy originates in supervisorial VGRS staff, not operations staff. Bill wrote: Clearly, this .com registry operator is not trustworthy. I think everyone in the DNSSEC community holds this view, and we're all attempting to work towards trust in the DNS. It may not be possible for the .com zone, for reasons that frankly appear to be policy based rather than mechanism based, but as things stand, the .com registry operator is not trustworthy. There are registry operators to who's operational art even less trust can be associated, e.g., NeuStar, my former employeer, and registry operators to who's operational art more trust can be associated, e.g., SWITCH. I'm sorry you felt that citing Martians was responsive to Bill's comments. I don't think they were. I'm rather fond of Martians. Bogons too. Eric -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

4 5

RE: Gtld transfer process
by Bruce Tonkin 18 Jan '05

18 Jan '05

Hello Brandon, Thanks for your feedback. > > My experience has been that getting auth_info (which criminal > staff would have access to) from bad registrars is almost > impossible, with registrar-LOCK too they have enough control > to negate the gain in being able to pull a domain to a new > registrar - you still need the cooperation of the old one so > it's just as bad as the old way but lots more risk for everyone > > EPP is thus of no advantage and registrar pull is dangerous Thus are you basically proposing that the registrant rely on cooperation with the old registrar, and if that fails, rely on ICANN to enforce compliance if the old registrars doesn't cooperate? I think in any model, unless ICANN enforces compliance the model will fail. We use the EPP model with registrar pull in Australia, and I haven't heard of any recent instances of abuse. There is no mechanism for the losing registrar to deny a transfer. The difference is that the ICANN equivalent in Australia (auDA) rigorously enforces compliance by the gaining registrar. Regards, Bruce

2 1