May 2000 - Test - lists.nanog.org

tcp port 8311?
by Brent Sweeny 03 May '00

03 May '00

we're seeing what appears to be a new large stream of data going outbound on tcp port 8311 and we can't identify a corresponding new application-- destinations are varied, with streams in the range of 50-100MBs each. Do any of you have any ideas what this is, and where to find out more about it? is this a new Napster? thanks, -- Brent Sweeny, Indiana University

3 2

Denver power outage
by Sean Donelan 02 May '00

02 May '00

Construction work near 55th cut power to the office park housing some of the regional Denver exchange points and regional ISPs. Some ISPs appear to be up on generators, others are unreachable at this time.

1 0

Security Expectations for Internet Service Providers to BCP
by Randy Bush 02 May '00

02 May '00

have providers looked at this document? draft-ietf-grip-isp-expectations-03.txt any significant constructive comment? randy

4 3

Re: Apache.ORG Website
by Branden R. Williams 02 May '00

02 May '00

On Tue, 2 May 2000, Adam McKenna wrote: > Why exactly did you email nanog and not someone at apache.org? I emailed webmaster and root at apache at 7:30AM CDT today. I don't have any other apache emails because they are all on the website :) This obviously did not work so I thought a last ditch effort would be to email nanog. > On Tue, May 02, 2000 at 09:49:48AM -0500, Branden R. Williams wrote: > > > > Ironically, the webserver on this machine has appeared to crash. FTP and > > other services work, but the HTTP service is dead. > > > > Thought I'd email and see if there was anyone who might be able to fix it. > > > > Cheers, > > > > Branden R. Williams <brw(a)netvitality.net> > > Vice President, Systems - NetVitality, Inc. > > http://www.netvitality.net/ > > Internet Commerce Specialists > > > > > > > Cheers, Branden R. Williams <brw(a)netvitality.net> Vice President, Systems - NetVitality, Inc. http://www.netvitality.net/ Internet Commerce Specialists

1 0

Apache.ORG Website
by Branden R. Williams 02 May '00

02 May '00

Ironically, the webserver on this machine has appeared to crash. FTP and other services work, but the HTTP service is dead. Thought I'd email and see if there was anyone who might be able to fix it. Cheers, Branden R. Williams <brw(a)netvitality.net> Vice President, Systems - NetVitality, Inc. http://www.netvitality.net/ Internet Commerce Specialists

1 0

4-port Ethernet
by David Lesher 01 May '00

01 May '00

After a slug of requests: IC Intracom 800-881-7325 The 10BaseT are Realtek chipsets, the 100 is Tulip (or so they said). I have no idea re: xBSD, but Don Becker told me the Linux drivers would be OK. (Note neither he nor I has handled the cards yet...) -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

2 5

Re: Re: external access and passwd mgmt (was Re: SSH on Cisco ...)
by Shawn McMahon 01 May '00

01 May '00

A lengthy discussion of why wouldn't be on topic here in NANOG, but it's a basic principle of computer security that if your password is so long that you must write it down to remember it, it is by definition too long. It is better to have a less-"secure" password that is not written down anywhere. If you must write a password down somewhere, it should be in a safe-deposit box that nobody has access to, so that it can only be recovered after your death. If you must write a password down electronically, it should encrypted, which makes it no better than the password of the encrypted database, so passwords should just plain flat never be so long that you have to write them down. The Gnu Keyring exists so that: 1) We can keep track of more passwords as securely as possible. 2) We can keep track of too-long passwords assigned to us by well-meaning folks. 3) We can keep track of long non-password numbers without having to haul around dangerous things like credit cards. :-) If you worked for me, I'd ask you to destroy that piece of paper and not do it again. On Mon, 1 May 2000, Bennett Todd wrote: > > I recommend instead picking an _exceptionally_ strong, > computer-generated random password for the keyring itself, and > writing it down on a slip of paper in your wallet until you've used > it enough times to memorize it.

2 1

Re: Cutting to the chase (was RE: ABOVE.NET SECURITY TRUTHS?)
by Sean Donelan 01 May '00

01 May '00

On Mon, 01 May 2000, Jeff Haas wrote: > Even when one exposes the issues in one's network/equipment/etc. one > still airs dirty laundry. The trick is to make sure it stinks as > little as possible. Unfortunately, the longer the dirty laundry sits > at the bottom of the pile, the worse it will stink when it ends up on > the top. Has anyone yet gotten a formal explaination from MCI/Worldcom about their frame-relay outage last summer. Last word I heard was their lawyers were reviewing a statement, but I never heard anything more. While its true corporations and people are more likely to publicize their successes rather than their failures, its also important to remember most of the early comments are just speculation. Is that good or bad? Its good to brainstorm all possibilities. Its bad because sometimes someone may take the early speculation as confirmation of fact. For example, shortly after the Abovenet incident, Computerworld wrote this characterization of a conversation with one of the executives involved. "Vixie says the company has speculated widely as to the motive for the attack and concluded that it could have emerged from one of two "completely useless categories." One category includes competitors that the company took a customer away from, disgruntled former employees or customers who had been disconnected because they were spamming. The other category, said Vixie, includes "someone who has something to prove and wants to bring our network down and wants to brag about it." Looking at the historical record, Paul's categorization is probable. But it is also possible Paul was completely wrong, and the cause or motivation was something other than the possibilities listed. Should we gag executives to prevent them from speculating because some of their speculation will be wrong? No. Its important we get as many possibilities on the table. But we need to remember, some of it will be incomplete or just wrong. We shouldn't crucify them for being wrong. Knowingly giving out misleading or false information is a different matter. I still think this industry will eventually need some method to obtain independent review of incidents.

2 1

RE: ABOVE.NET SECURITY TRUTHS?
by Exiled Dave 01 May '00

01 May '00

A thought just came to me. My experience with above.net, and exodus.net, leaves me to KNOW that a certain exodus engineer's wife works as an engineer at above.net. Reading the quote at http://www.cnn.com/2000/TECH/computing/04/28/fbi.abovenet.idg/index.html Quoted: "Vixie says the company has speculated widely as to the motive for the attack and concluded that it could have emerged from one of two "completely useless categories." One category includes competitors that the company took a customer away from, disgruntled former employees or customers who had been disconnected because they were spamming. The other category, said Vixie, includes "someone who has something to prove and wants to bring our network down and wants to brag about it." " Ebay WAS at exodus, then half of it went to above. Maybe this is just the "conspirator" in me, but, what if that husband/wife team was 'contracted' for revenge, for the ebay move, and participated in paid corporate espionage? :) __________________________________________________ Do You Yahoo!? Talk to your friends online and get email alerts with Yahoo! Messenger. http://im.yahoo.com/

8 8

Reminder - NANOG proposal deadline
by Susan R. Harris 01 May '00

01 May '00

* * * * * * * * * * * * * * * * * CALL FOR PRESENTATIONS * * NANOG 19 * * June 11 - 13, 2000 * * * * * * * * * * * * * * * * * The North American Network Operators Group (NANOG) will hold its 19th meeting in Albuquerque, NM, between June 11 - 13, 2000. The meeting will be hosted by iHighway. NANOG conferences provide a forum for the coordination and dissemination of technical information related to large-scale (i.e., national/international) Internet backbone networking technologies and operational practices. NANOG meetings, held three times each year, include two days of short presentations, plus afternoon/evening tutorial sessions. Meetings are informal, with an emphasis on relevance to current backbone engineering practices. The conference draws around 500 participants, mainly consisting of engineering staff from large national service providers, and members of the research and education community. Now in its fifth year, NANOG evolved from the NSFNET "regional-techs" meetings, where technical staff from the regional networks met to discuss operational issues of common concern. With the emergence of the commercial Internet, NANOG meetings evolved to include a broader base of providers, network operators, and researchers. The meeting will be held at the Albuquerque Hyatt Regency. For more information about NANOG meetings, schedules, and logistics, see: http://www.nanog.org ------------------------------------------------------------------------------ CALL FOR PRESENTATIONS NANOG invites presentations on backbone engineering, coordination, and research topics. Presentations should highlight issues relating to technology already deployed or soon to be deployed in core Internet backbones and exchange points. Previous meetings have included presentations on: - Backbone traffic engineering - Coordination of inter-provider QoS - Deployment experience with queueing disciplines (CAR, RED) - Inter-provider security and routing protocol authentication - Routing scalability in backbone infrastructures - Security issues for the Internet core - Routing policy specification and backbone router configuration - Building large-scale measurement infrastructure - Cooperative inter-provider caching - Alternatives to hot-potato routing - Recommendations on queue management and congestion avoidance - Experience with differentiated services - Reports from next-generation networks (Internet2, CA*net, etc.) - Inter-domain multicast deployment - Backbone network failure analysis Tutorials have covered topics such as: - BGP case studies - MPLS fundamentals - External route selection - IP multicast technologies - Distributed content caching in large IP networks ------------------------------------------------------------------------------ HOW TO PRESENT Submit an informal one- or two-paragraph abstract describing the presentation in email to nanog-support(a)nanog.org. The deadline for proposals is May 8, 2000. The majority of speaking slots will be filled by May 8; a limited number of slots will be available after that date for topics that are exceptionally timely and important. Presenters will be notified of acceptance by May 22, 2000. NANOG also welcomes suggestions/recommendations for tutorials, panels and other presentation topics. ------------------------------------------------------------------------------

1 0