- Test - lists.nanog.org

ICANN - The Case for Replacing its Management
by Patrick 07 Mar '02

07 Mar '02

Although I reserve comment on some of the specific recommendation offered by the author, this is an otherwise extremely timely, well-articulated view into the history of ICANN to present written by the former Chair of the General Assembly. http://www.icannworld.org P.S. Yes Virgina, the resultant outcome of this mess could actually affect how you configure your router(s) some day.... /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Asking the wrong questions is the leading cause of wrong answers \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

18 27

Re: Telco's write best practices for packet switching networks
by Steven M. Bellovin 07 Mar '02

07 Mar '02

In message <gu9ofi1rcwe.fsf(a)rampart.argfrp.us.uu.net>, Eric Brandwine writes: > >Firewalls are good things for general purpose networks. When you've >got a bunch of clueless employees, all using Windows shares, NFS, and >all sorts of nasty protocols, a firewall is best practice. Rather >than educate every single one of them as to the security implications >of their actions, just insulate them, and do what you can behind the >firewall. > >When you've got a deployed server, run by clueful people, dedicated to >a single task, firewalls are not the way to go. You've got a DNS >server. What are you going to do with a firewall? Permit tcp/53 and >udp/53 from the appropriate net blocks. Where's the protection? Turn >off unneeded services, chose a resilient and flame tested daemon, and >watch the patchlist for it. Precisely. You *may* need a packet filter to block things like SNMP (to name a recent case in point), but a general-purpose firewall is generally the wrong solution for appliance computers. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

6 7

Re: Equinix Exchange Point
by Reggie Forster 07 Mar '02

07 Mar '02

XO is... At 09:14 AM 3/7/02, Guy.Ram(a)usa.telekom.de wrote: >Quick poll to see who's at or planning to be at the Equinix Asburn exchange >point. > >thanks, > >-guy

1 0

Re: Equinix Exchange Point
by renster 07 Mar '02

07 Mar '02

SBC is. Also at Dallas & San Jose now. Soon to be at Los Angeles & Chicago. http://www.sbcbackbone.net/peering/ -ren At 09:14 AM 3/7/2002 -0500, Guy.Ram(a)usa.telekom.de wrote: >Quick poll to see who's at or planning to be at the Equinix Asburn exchange >point. > >thanks, > >-guy

1 0

RE: Equinix Exchange Point
by Allison.Feese＠Broadwing.com 07 Mar '02

07 Mar '02

Broadwing will be there sometime between April and May. Allison -----Original Message----- From: Guy.Ram(a)usa.telekom.de [mailto:Guy.Ram@usa.telekom.de] Sent: Thursday, March 07, 2002 8:14 AM To: nanog(a)merit.edu Subject: Equinix Exchange Point Quick poll to see who's at or planning to be at the Equinix Asburn exchange point. thanks, -guy +++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++

1 0

RE: Equinix Exchange Point
by Hallgren, Michael 07 Mar '02

07 Mar '02

> > > Quick poll to see who's at or planning to be at the Equinix > Asburn exchange > point. Teleglobe is. mh > > thanks, > > -guy >

1 0

216.119.248.0/21
by J.D. Falk 07 Mar '02

07 Mar '02

Has ARIN begun assigning from 216 (but not updating whois), or is AS16994 playing silly buggers here? (Apparently this network was sending spam.) route-views.oregon-ix.net>sh ip bgp 216.119.251.98 BGP routing table entry for 216.119.248.0/21, version 1338771 Paths: (53 available, best #14) Advertised to non peer-group peers: 64.166.72.140 3333 9057 3549 11456 11456 16994 193.0.0.56 from 193.0.0.56 (193.0.0.56) Origin IGP, localpref 100, valid, external 7018 3549 11456 11456 16994 192.205.31.33 from 192.205.31.33 (192.205.31.33) Origin IGP, localpref 100, valid, external 8918 3356 11456 11456 16994 212.4.193.253 from 212.4.193.253 (212.4.193.253) Origin IGP, localpref 100, valid, external 6395 3356 11456 11456 16994 216.140.8.63 from 216.140.8.63 (216.140.8.63) Origin IGP, metric 416, localpref 100, valid, external Community: 6395:200 6395:1005 4006 3549 11456 11456 16994 205.215.45.50 from 205.215.45.50 (205.215.45.50) Origin IGP, localpref 100, valid, external 5056 701 3549 11456 11456 16994 167.142.3.6 from 167.142.3.6 (167.142.225.101) Origin IGP, localpref 100, valid, external [snip] -- J.D. Falk "The kick defines the beat, <jdfalk(a)cybernothing.org> the bass defines the groove." -- Phil Lockwood

3 3

Re: Telco's write best practices for packet switching networks
by Simon Higgs 06 Mar '02

06 Mar '02

At 06:30 PM 3/6/2002 +0000, you wrote: >In most people's example networks they PROBABLY run all their 'services' >on virtual interfaces anyway so ssh doesn't have to listen on the same ip >as bind so perhaps it's a non-issue. Does anyone have a good reference for this particular solution? Most software is really badly documented when it comes to this, and without configuration the service ends up on all the interfaces (or even just localhost). Popular services like BIND and Sendmail are easy enough to configure, but, documentation wise, this topic now reminds me of trying to find decent rwx anon ftp instructions ten years ago. Best Regards, Simon -- ###

1 0

Re: Telco's write best practices for packet switching networks
by Eric Brandwine 06 Mar '02

06 Mar '02

>>>>> "rp" == Rob Pickering <rob(a)pickering.org> writes: rp> --On 06 March 2002 15:04 +0000 "Christopher L. Morrow" <chris(a)UU.NET> rp> wrote: >> Eric's point was you deploy your fancy-dan mail server with ONLY 22 >> and 25 listening, rp> Um, that would be "ONLY port 25 listening" on it's public network rp> facing interface wouldn't it. rp> Why would you want to expose a management protocol like ssh to the rp> Internet? You wouldn't. Neither would I. I'll go poke fun at Chris. rp> OK so leaving ssh open is convenient, but if we are talking best rp> practice surely having your remote management protocols running on a rp> separate network, or at the very least filtering on a host basis so rp> that it's only listening to connects from your NOC has to be the way rp> to do this. Absolutely. It bothers me that as an ISP, we kinda have to run mail and dns servers. If there were two protocols I'd choose NOT to expose to the public network, they'd be it. I'd much rather expose ssh than bind or sendmail. ericb -- Eric Brandwine | Apart from hydrogen, the most common thing in the UUNetwork Security | universe is stupidity. ericb(a)uu.net | +1 703 886 6038 | - Harlan Ellison Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E

3 2

Re: Telco's write best practices for packet switching networks
by Eric Brandwine 06 Mar '02

06 Mar '02

>>>>> "rq" == Rob Quinn <rquinn(a)sec.sprint.net> writes: >> When you've got a deployed server, run by clueful people, dedicated to a >> single task, firewalls are not the way to go. rq> Probably. And I would certainly rate "clueful people" _far_ rq> above a firewall when it comes times to prioritize your security rq> needs and resources. Mind having a talk with my management? >> chose a resilient and flame tested daemon, and watch the patchlist for it. rq> You've never seen a security vendor come out with a patch or rq> workaround before an application vendor? Sure. Sometimes they come out with patches that wouldn't be needed if you didn't have the firewall ;) Stateful firewalls also suffer from state propagation problems. High bandwidth redundant links and firewalls don't get along well together. Some firewall packages will allow you to statelessly pass high bandwidth traffic (tcp,udp/53) in the DNS example, which helps with load management and failover. But then you're back to where you were without the firewall. Decent IDSes run on spanning ports against your uplinks, decent logging on packet filtering routers, etc will all give you the benefits of the firewall. In general, and IDS is a better IDS than a firewall, and so forth. The primay benefit of firewalls is simplicity of configuration, and the ability to allow outbound services without opening huge inbound holes (tcp,udp/53, tcp/20, udp > 1023, etc). This is generally not the case with deployed ISP servers. Finally, the "crunchy ouside" thing takes over way too often. Management is lulled into a happy place by the word "firewall", and even good security engineers get lazy. I realize that this is 100% a meat problem, but it's a problem either way. ericb -- Eric Brandwine | If people are good only because they fear punishment, UUNetwork Security | and hope for reward, then we are a sorry lot indeed. ericb(a)uu.net | +1 703 886 6038 | - Albert Einstein Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E

1 0