March 2001 - Test - lists.nanog.org

Apple security contact?
by David Lesher 13 Mar '01

13 Mar '01

Sorry to interupt the rancher vs cattleman range war.... Can anyone point me to a contact person at Apple to answer a network/security query? Thank you; you may resume shooting. -- 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

1 0

RE: Statements against new.net?
by Roeland Meyer 13 Mar '01

13 Mar '01

> From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Tuesday, March 13, 2001 12:26 PM > I have to ask if any of these people who advocate the new.net approach > have been in the business long enough to have diagnosed > problems caused > by "I've got the Sep 1 hosts.txt, but you've go the July 15 > and they've > got the Sep 22" version. > > I *thought* we learned our lesson. Apparently not. We did, that's why we use DNS. As long as we practice collision avoidance, we won't have any problems. However, those that intentionally collide must be made to pay for it. ICANN, by flat-out ignoring the existing RSCs, basically told the rest of the world that it is okay for everyone else to ignore each other too. Had ICANN even tried to include the existing RSCs, we would now have new, non-colliding, TLDs.(IMHO) Personally, from my vantage point, the Internet co-opetition model is collapsing. Co-operation is a tit-for-tat game and no one is going to play without some "quid pro quo". ICANN wants it all one-way and that isn't going to happen anytime soon. In fact, such policy stance encourages polarization and fragmentation of the market/community. This is what gave rise to the opportunity that new.net is trying to exploit. Inclusive co-opetition would not have prevented the rise of new.net, but it would have given them strong encouragement to NOT have colliding TLDs. BTW: Co-opetition ::= cooperative competetion.(coined elsewhere)

1 0

Re: UUNet / ATT peering meltdown?
by Sean Donelan 13 Mar '01

13 Mar '01

On Tue, 13 March 2001, Travis Pugh wrote: > Not to open up any potential disputes, but has anyone heard what is going > on between UUNet and AT&T on the east coast? We've been seeing this kind > of performance for a week ... standard UUNet NOC response was "it's ATT's > problem, call them" which doesn't do me a whole lot of good since we're > not an ATT customer. AT&T had a fiber cut in Atlanta last week. They may still be operating on alternate facilities.

1 0

RE: UUNet / ATT peering meltdown?
by Travis Pugh 13 Mar '01

13 Mar '01

That may be a little extreme ... I generally get good support from all of my upstreams. However, there's a certain amount of static to be expected when you start raising inter-provider issues, especially when all the latency seems be caused by the provider you aren't a customer of. -travis On Tue, 13 Mar 2001, Tom Thomas wrote: > Bad attitudes to a customer are a clear indication you should take your > money elsewhere. > > Personally I like NetRail, they are courteous and responsive. > > > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Travis Pugh > Sent: Tuesday, March 13, 2001 1:13 PM > To: nanog(a)merit.edu > Subject: UUNet / ATT peering meltdown? > > > > > Not to open up any potential disputes, but has anyone heard what is going > on between UUNet and AT&T on the east coast? We've been seeing this kind > of performance for a week ... standard UUNet NOC response was "it's ATT's > problem, call them" which doesn't do me a whole lot of good since we're > not an ATT customer. > > UUNet --> ATT > > 6 POS6-0.BR3.NYC9.ALTER.NET (152.63.24.97) 9.212 ms 9.633 ms 10.363 > ms > 7 137.39.52.74 (137.39.52.74) 9.642 ms 12.967 ms 12.137 ms > 8 gbr3-p50.n54ny.ip.att.net (12.123.1.122) 418.555 ms 416.419 ms > 419.819 ms > > ATT --> UUNet > > 8 ggr1-p370.attga.ip.att.net (12.123.20.253) [AS 7018] 20 msec 24 msec > 20 msec > 9 att-gw.atl.uu.net (192.205.32.130) [AS 7018] 396 msec 396 msec 392 > msec > 10 179.at-6-0-0.XR1.ATL5.ALTER.NET (152.63.82.190) [AS 701] 388 msec 388 > msec 388 msec > > Thanks. > > -travis > > > >

1 0

BGP listserv
by Berger, Gary 13 Mar '01

13 Mar '01

Is there a list that purely discusses BGP? Gary Berger Internal Consultant, Principal Dow Jones & Company Enterprise Network Services Voice: 609.520.7323

3 2

News Feed
by Morris Allen 13 Mar '01

13 Mar '01

Off topic Question. Does any body have any information on News Server Feeds. I have lost my, and need to locate another that doesn't want an arm and a leg for a small ISP. Thanks Morris Allen VidcomNet, Inc. P.S. Please reply private to: mallen(a)vidnet.net

2 1

RE: Filtering email messages for canned ham
by Smith, Rick 13 Mar '01

13 Mar '01

I forgot to mention I'm already using rblsmtpd to work with blackhole lists. R -----Original Message----- From: Smith, Rick [mailto:rsmith@atsworld.com] Sent: Tuesday, March 13, 2001 9:17 AM To: 'nanog(a)merit.edu' Subject: Filtering email messages for canned ham Evidently, Nanog(a)merit.edu doesn't accept emails with the four letter word interpretation of my subject line. I have a machine which is the primary MX for my network, a linux box running Qmail (1.03) which scans every inbound mail to my domain for viruses before being passed on to the secondary MX, an Exchange Server. That works well, so I'd like to break the whole thing by adding to it some means of filtering out UCE / <Canned Ham> ;) Anyone used or know of tools that are written for Qmail's interaction ? Thanks, Rick Smith Director of Technical Services Applied Tactical Systems (A division of Vertex Interactive, Inc.) <http://www.atsworld.com> --- <http://www.vertexinteractive.com> (973) 808 - 1750 x382

1 0

Filtering email messages for canned ham
by Smith, Rick 13 Mar '01

13 Mar '01

Evidently, Nanog(a)merit.edu doesn't accept emails with the four letter word interpretation of my subject line. I have a machine which is the primary MX for my network, a linux box running Qmail (1.03) which scans every inbound mail to my domain for viruses before being passed on to the secondary MX, an Exchange Server. That works well, so I'd like to break the whole thing by adding to it some means of filtering out UCE / <Canned Ham> ;) Anyone used or know of tools that are written for Qmail's interaction ? Thanks, Rick Smith Director of Technical Services Applied Tactical Systems (A division of Vertex Interactive, Inc.) <http://www.atsworld.com> --- <http://www.vertexinteractive.com> (973) 808 - 1750 x382

1 0

Prefix length filtering at the ISP-ISP edge
by Alexandre.Gibouin＠sita.int 13 Mar '01

13 Mar '01

Nothing new in this mail but I need some clarification ... - To my understanding, the common practice is, at least, to accept any address block larger or equal to /19 and to filter any block smaller than /24 (except eventually at the customer-ISP edge). ARIN and RIPE have changed for a while their minimum allocation size to /20 so I guess there is no risk of routing blackhole with /20 blocks, right? - What about PI-blocks between 21 and 24 bits? If a end-user network annouces such an address block, what is the risk of routing blackholes throughout the Internet? - Each ISP seems to apply its own filtering policy. Nevertheless, what are the most common filtering practices for the ISP-ISP edge? - Is it common to have different filtering policies depending on the address ranges? I will be grateful for any link to official or non-official documentation. Thanks for your help Alex

1 0

Looking Glass Code
by Don Simpson 13 Mar '01

13 Mar '01

I have been thinking about putting together a looking glass site on my network and have looked at Ed Kern's (DIGEX) html and perl script but do not want to enable rsh (anywhere) and do not want to reinvent the wheel if not necessary. Has anyone seen an updated script written to use other access means like telnet or ssh to exchange CLI/commands and results with an IOS router? ---------------------------------------------- Don Simpson ----------------------------------------------

6 5