September 2005 - Test - lists.nanog.org

Re: Buh bye
by Scott Weeks 06 Sep '05

06 Sep '05

----- Original Message Follows ----- From: "Jay R. Ashworth" <jra(a)baylink.com> To: nanog(a)merit.edu Subject: Buh bye Date: Tue, 6 Sep 2005 15:24:48 -0400 > I'm about to be removed, forcibly, from nanog-post. It doesn't matter what it's for, I thought there was a "no censorship" agreement in the "new" NANOG. We can procmail. Did I miss something? scott

2 1

RE: Technical contact at Cogent
by David Hubbard 06 Sep '05

06 Sep '05

From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > > Can someone from Cogent or with a technical contact there (other than > noc(a)cogent.com) contact me offlist? I would like to discuss some BGP > issues with them. > > Thanks very much, > > Tao Wan > twan(a)scs.carleton.ca > You've already tried calling them and gotten no response? Unlike some other providers, Cogent's number on their web site has always worked well for me. David

1 0

DARPA and the network
by Michael.Dillon＠btradianz.com 06 Sep '05

06 Sep '05

Since the modern military runs on networks, DARPA funds various programs to make networks better and more secure. One of these was CHATS. Here is the business case taken from the DARPA budget justification: ------ The Composable High Assurance Trusted Systems (CHATS) program is developing the tools and technology that enable the core network services to be protected from the introduction and execution of malicious code or other attack techniques and methods. These tools and technologies will provide the security services needed to achieve comprehensive-secure, highly distributed, mission-critical information systems for the DoD. A unique feature of CHATS is that these system capabilities will be developed by engaging the open-source community in security functionality for existing open-source operating systems. Additionally, DARPA will engage the open-source community in a consortium-based approach to create a ?neutral?, secure operating system architecture framework. This security architecture framework will then be used to develop techniques for composing OS capabilities to support both servers and clients in the increasing network-centric communications fabric of the DoD. In FY 2003 the CHATS program will move to project ST-24 in this program element. ------ For a time, DARPA even funded the ongoing work of the OpenBSD team but political disagreements over the Iraq war scuttled that work. In roughly the same time frame, there was a project called LSAP (Linux Security Audit Project) that attenmpted to extend the methodology of OpenBSD to Linux. This was succeeded by Sardonix which attempted to create a register of all audited open source software. For various reasons both of these projects fizzled. So why did OpenBSD succeed in their rigorous audit process? I believe it is because there was a firm hand at the helm who was able to keep them focused on their non-profit goal, namely secure operating software. Now corporations do share one characteristic with OpenBSD which should allow them to be able to succeed in the same way. They have firm hands at the helm. However, they also have the profit motive and it is often possible for corporations to avoid security issues in their systems and make profits anyway. That's where NANOG comes in. We are the customers of the router and switch manufacturers. We have the ability to tie the corporate profit motive together with a security imperative. I know that people on this list would rather talk about how to tweak the boxes and protocols to do the best with what we have available, but I think times have changed. The global community of hackers is our Al Qaeda, a leaderless mob that wants to break the network and control the network. If we want to prevent this, then we have to work as hard and as smart as the many people who are tackling Islamist terrorist cells. It's no longer good enough to just do the best we can with the boxes that vendors give us when those boxes are so easily compromised and when there is a community of people who are specifically targetting those boxes, unlike in the past. --Michael Dillon

9 13

Buh bye
by Jay R. Ashworth 06 Sep '05

06 Sep '05

I'm about to be removed, forcibly, from nanog-post. Mostly, it's because I feel that the degree of stink raised by the admin team over my "send in the marines" post last week is completely out of the bounds of reason for a single, only arguably off-topic, posting which asked for, and received, no on-list replies. And, clearly, they *don't* think it's unreasonable. That's ok; I only operate very small networks, and no one's going to lose any sleep over not hearing what I have to say. And since, notwithstanding everyone's interest in *reading* best practices information on networking, none of the people who *have* it had anything to write about it on the Wikicty below (with a couple of notable exceptions), I'm probably taking that off in another direction as well. I wrote this mostly because it's a tradition. :-) Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer +-Internetworking------+----------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me

1 0

Re: ISMS working group and charter problems
by Steven M. Bellovin 06 Sep '05

06 Sep '05

In message <431DD94C.8070907(a)dcrocker.net>, Dave Crocker writes: > > >(By the way, I am awestruck at the potential impact of changing SNMP from >UDP-based to TCP-based, given the extensive debates that took place about this >when SNMP was originally developed. Has THIS decision been subject to adequate >external review, preferably including a pass by the IAB?) When I was the sponsoring AD for the group, I pushed back hard on this point. The WG opted for the present path. I'm not saying they're right -- in fact, I disagreed -- but the decision wasn't made by default. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

1 0

Re: ISMS working group and charter problems
by Eliot Lear 06 Sep '05

06 Sep '05

Daniel, All solutions will use a different SSH port as part of the standard just so that firewall administrators have the ability to block. Eliot Daniel Senie wrote: > At 02:00 PM 9/6/2005, Dave Crocker wrote: > > >> Eliot, >> >>> I need your help to correct for an impending mistake by the ISMS >>> working group in the IETF. >> >> >> >> Your note is clear and logical, and seems quite compelling. >> >> Is there any chance of getting a proponent of the working group's >> decision to post a defense? >> >> (By the way, I am awestruck at the potential impact of changing SNMP >> from UDP-based to TCP-based, given the extensive debates that took >> place about this when SNMP was originally developed. Has THIS >> decision been subject to adequate external review, preferably >> including a pass by the IAB?) > > > I agree the argument is well laid out, and would be interested in > hearing the thinking of ISMS in response. > > I'm more than a bit concerned, however, when folks start talking about > solutions that will permit things to pass through firewalls without > configuration. Those in charge of firewalls are often purposely setting > policy. If there is a perceived need for a policy that prevents SNMP > traffic, then it should remain possible for the administrator of that > network element to make that call. I must say I have some concern with > overlaying SNMP on SSH, since that precludes the firewall knowing > whether the traffic is general SSH keyboard traffic or network management. > > Let's hear more about the thinking involved. >

1 0

P2P Darknets to eclipse bandwidth management?
by Fergie (Paul Ferguson) 06 Sep '05

06 Sep '05

Interesting article, and something I think that will certainly becaome an issue for ISPs. Is this a real issue ISPs are thinking about? Via The Register: [snip] Encrypted P2P networks will soon make bandwidth management based on deep packet inspection obsolete, says Staselog, a Finnish appliance outfit. Around 80 per cent of all traffic in the Internet is already P2P. This traffic will increase 1,000-fold in the next five years and most of it will be encrypted P2P, according to a study by Staselog and researchers at Finnish Universities. [snip] http://www.theregister.co.uk/2005/09/01/darknets_fox_traffic_manage_tech/ Overlooking the point that this kind of smells like a pitch for Staselog, I'd be curious to hear of this is an issue on ISP bandwidth management radar... or already is... - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

6 5

Any issue with www.cisco.com
by Hyunseog Ryu 06 Sep '05

06 Sep '05

Last night I had a maintenance so I use www.cisco.com for testing the network connectivity. But it seems that I'm seeing about 20% packet loss from www.cisco.com. I did same test from various points including my home cable modem connection, which is not my company's network, but I'm getting same result. Are you guys seeing same thing or different result? Is there any issue with cisco.com network? Hyun

7 6

RE: level3.net in Chicago - high packet loss?!?
by Min Qiu 06 Sep '05

06 Sep '05

Stef, > -----Original Message----- > From: Network Fortius [mailto:netfortius@gmail.com] > Sent: Tuesday, September 06, 2005 10:25 AM > To: nanog(a)merit.edu > Subject: Re: level3.net in Chicago - high packet loss?!? > > > > And how exactly would you interpret the number returned by net_loss > (int), in a column called "LOSS", in reference to reachability of a > "hop" between two end points: > > int net_loss(int at) > { > if ((host[at].xmit - host[at].transit) == 0) > return 0; > /* times extra 1000 */ > return 1000*(100 - (100.0 * host[at].returned / (host[at].xmit - > host[at].transit)) ); > } ? This piece of code is modified by me (all mistake is mine). It converts the the drop to percentage. x 1000 was a trick to handle none int returned by the function. This was an issue I did not have a clear answer. Regarding to you original post. Your trace end2end (last hop) has 0.0% drop proved the entire path was free of packet loss. The drop in the middle of the path could be related to ICMP rate limit or other things. Should it was a congestion in the X hop, every hop after X would be impacted by it. Thus X+1, X=2... has to be > 0.0%. Hope this help, Min > > Thanks, > Stef > Network Fortius, LLC > > > On Sep 6, 2005, at 7:45 AM, Robert E.Seastrom wrote: > > > > > Network Fortius <netfortius(a)gmail.com> writes: > > > > > >> Anybody having any idea why such a high packet loss on lever3's > >> network, in Chicago? > >> > > > > End-user misinterpreting output from MTR. This network does not > > appear to have any packet loss end-to-end. > > > > ---Rob > > > > > > > >> Stef:~ scm$ mtr -r www.yahoo.com > >> ... > >> tbr1-p010802.cgcil.ip.att.net 0% 16 16 15.12 > >> 24.21 49.26 > >> ggr2-p310.cgcil.ip.att.net 0% 16 16 13.18 > >> 42.66 118.99 > >> so-1-1-0.edge1.chicago1.level3.net 0% 16 16 14.48 > >> 35.84 126.48 > >> so-2-1-0.bbr1.chicago1.level3.net 63% 6 16 14.44 > >> 43.74 79.97 > >> > > >> ^^^^^^^ > >> as-1-0.bbr2.sanjose1.level3.net 0% 16 16 61.95 > >> 80.64 176.01 > >> ge-10-2.ipcolo3.sanjose1.level3.net 0% 16 16 63.37 > >> 95.61 148.46 > >> unknown.level3.net 0% 16 16 63.34 > >> 86.46 168.62 > >> unknown-66-218-82-217.yahoo.com 0% 16 16 62.09 > >> 88.91 127.58 > >> p4.www.scd.yahoo.com 0% 16 16 64.51 > >> 89.96 183.79 > >> > >> TIA, > >> Stef > >> Network Fortius, LLC > > > >

1 0

$400 to $600 million Bellsouth repairs
by Sean Donelan 06 Sep '05

06 Sep '05

A map showing the geographic span of the disaster. It extends far beyond New Orleans, across Mississippi and Alabama. Some service in the worst areas may not be restored for months. http://www.nytimes.com/2005/09/06/business/06telecom.html

1 0