March 2003 - Test - lists.nanog.org

RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)
by McBurnett, Jim 11 Mar '03

11 Mar '03

Idea #2.. CNN.com-- Put some of their content.. They would probrably really enjoy the publicity.. And that would really be an educational point.. Anybody here from there??? Jim > The suggestion of putting Yahoo or Google on a 69/8 IP led me to this > idea: > > Google could put their *beta* sites on a 69/8 IP, without > causing them > (Google) much Internet reachability/connectivity harm, and benefiting > the Internet at large considerably. > > Set up a page (hopefully linked from www.google.com) that > lists all of > Google's present beta sites.

1 0

Re: 69/8...this sucks
by Larry J. Blunk 11 Mar '03

11 Mar '03

Appologies for the poor attempt at humor... However, there is some useful content at the end of the message. Essentially, I think this is one of those problems that can never fully be solved. Just as we will never get every last worm-infected host off the network. The best that we can do is provide procedures for those who filter on unallocated space so than can keep their filters updated on a timely and accurate basis. For those who do not wish to use such procedures, we should stridently urge them to filter only on martians, not unallocated space. -Larry Blunk Merit > I agree. > > -----Original Message----- > From: Rick Duff [mailto:rduff@qwest.net] > Sent: Tuesday, March 11, 2003 2:09 PM > To: 'Larry J. Blunk'; 'Andy Dills' > Cc: 'Ejay Hire'; nanog(a)merit.edu > Subject: RE: 69/8...this sucks > > > > I've never posted to the list, just lurk, for over a year now, but this > has to be said. Can we please take this discussion off-list to private > conversation. It's gotten worse then spam. I see a nanog message and > just start deleting them now. > > -rd > > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Larry J. Blunk > Sent: Tuesday, March 11, 2003 1:01 PM > To: Andy Dills > Cc: Ejay Hire; nanog(a)merit.edu > Subject: Re: 69/8...this sucks > > > > > > > On Tue, 11 Mar 2003, Ejay Hire wrote: > > > > > Er, guys... How does this fix the problem of a Malicious user > > > advertising a more specific bogon route? > > > > Come on...clearly you haven't been paying attention. > > > > You need LDAP filters. LDAP filters and a South Vietnamese revolution > > against the IRRs for being fragmented and greedy. > > Careful. We are watching and are prepared to ruthlessly squash > any attempted rebellion. > > > > > And if that doesn't poison your inverse arp, then multiplex a private > > bogon server with a centralized host scanner-based DNSBL. Don't forget > the > > trailing dot! And don't forget to invert the subnet mask! > > > > Hey, I've already thought of all that and captured it in an > XML schema (with ASN.1 encoding)! I will be presenting an Internet > Draft next week at the IETF in the CRISP/RPSEC/GROW/IDR meetings. > > > Seriously... As has been suggested, I think we need to do > a better job of identifying the population and type of devices > that are filtering these prefixes. Are they really predominately > BGP speaking routers, or largely some mishmash of non-BGP speaking > firewalls/proxies/NAT's? > > If it's the former, then a BGP based solution has some merit. > If the latter, I think it unreasonable to expect these > firewalls to speak BGP. What's needed is a canonical > represention of the bogon list and some tools to generate > the filter list in the appropriate config format for a number > target devices. > > There's already a canonical list maintained by Rob Thomas > in the RADB (see fltr-martian, fltr-unallocated, and > fltr-bogons). I've suggested to Rob that he may want > to include a PGP signature in a remarks section of the object > to provide a greater level of confidence (hopefully with > a key that's escrowed somehow -- god forbid anything should > happen to Rob). I should also note that some of the > RIR's have indicated they will be providing more > precise information on their unallocated space. > > As far as tools go, while IRRToolSet has extensive > support for RPSL, it may be too complex for a novice > Net admin. Perhaps some simple Perl scripts to generate > filter configs from RPSL filter objects would be useful? > > > Larry Blunk > Merit >

1 0

(no subject)
by Stephen Gill 11 Mar '03

11 Mar '03

Hi Owen, This is exactly the service Team Cymru is currently offering with the bogon route-server project. Specific details and instructions on how to request access can be found at the following URL: http://www.cymru.com/BGP/bogon-rs.html In a nutshell, this is a reliable and secure method of ensuring your bogon routes are kept up-to-date. Changes to the bogon route-server are validated by at least two other individuals. Team Cymru validate all changes to the bogon lists and supporting documents prior to implementation of such changes. That said, bogons are updated almost immediately and at no cost to you. This is a *FREE* offering, as such there are NO guarantees or SLAs. The current list of 15 peers have been quite pleased with the reliability and service. We are also working on adding redundant bogon route-servers in the very near future. If anyone is willing to donate gear or bandwidth to the cause, please dont hesitate to contact us. As always, the master bogon reference page can be found here: http://www.cymru.com/Bogons/index.html Feel free to send any queries, suggestions, or concerns to the entire team at team-cymru(a)cymru.com. Thanks! Steve, for Team Cymru. -- Stephen Gill gillsr(a)cymru.com -----Original Message----- Date: Tue, 11 Mar 2003 08:48:07 -0800 From: Owen DeLong <owen(a)delong.com> Subject: RE: 69/8...this sucks -- Centralizing filtering.. Thanks for your support Jim. I've gotten mixed feedback to my proposal here for a centralized bogon filter from the RIRs via BGP, but I will say there's been more support than opposition. (Most of the support has been sent to me, not the list, while most of the opposition has been to the list, however). I know it's too late to get it into the Memphis meeting, but I think, based on the amount of support it has received, that I will submit a policy proposal to ARIN in support of creating the requisite BGP feeds. I realize that an ARIN policy alone won't do this (the other RIRs would have to follow suit), but, if ARIN adopts it, I don't think it will be too hard to get the other RIRs to follow. I'm also not familiar with the policy process in the other RIRs. I absolutely agree with you about the whois contact stuff. I think it might make sense eventually to put a similar requirement for current information on the admin and tech contact, although I don't see putting the same response and performance strictures on them. For now, I'm trying to address large issues in small enogh pieces to get rough consensus around the solution to each small piece. Trying to solve the big problems all at once never seems to achieve rough consensus. Owen

1 0

69/8 problem -- Would CNN care?
by Lee Watterworth 11 Mar '03

11 Mar '03

Over the last few years CNN has covered many internet tech articles -- various worms, attacks and outages. Think they would care to do a story on this problem? -Lee

2 1

OT: Increasing Cell Phone Signal inside a NOC?
by Spencer.Wood＠dot.state.oh.us 11 Mar '03

11 Mar '03

I'm sure a lot of people have the same problem as we are having... Our NOC and Server Equipment is located in "No Cell Phone signal" zone of our building (It's amazing what metal walls, Server Racks and HVAC Systems will do to Cellphone Signals). I was wondering if anyone out there has found a device that will be able to repeat the Cell Phone signal back into our NOC & Server Area's??? Any advice would be greatly appreciated! Spencer ************************************************************ Spencer Wood, Network Manager Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: Spencer.Wood(a)dot.state.oh.us Phone: 614.644.5422/Fax: 614.887.4021/Pager: 866.591.9954 *************************************************************

3 2

RE: Increasing Cell Phone Signal inside a NOC?
by Mike Damm 11 Mar '03

11 Mar '03

Wait; let me get this strait... you want people calling you on your cell when you're working in the NOC? Check out http://cellantenna.com/ for a solution that will run you anywhere from a grand on up. I haven't tested it myself though. -Mike --- Michael Damm, MIS Department, Irwin Research & Development V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com -----Original Message----- From: Spencer.Wood(a)dot.state.oh.us [mailto:Spencer.Wood@dot.state.oh.us] Sent: Tuesday, March 11, 2003 9:56 AM To: nanog(a)merit.edu Subject: OT: Increasing Cell Phone Signal inside a NOC? I'm sure a lot of people have the same problem as we are having... Our NOC and Server Equipment is located in "No Cell Phone signal" zone of our building (It's amazing what metal walls, Server Racks and HVAC Systems will do to Cellphone Signals). I was wondering if anyone out there has found a device that will be able to repeat the Cell Phone signal back into our NOC & Server Area's??? Any advice would be greatly appreciated! Spencer ************************************************************ Spencer Wood, Network Manager Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: Spencer.Wood(a)dot.state.oh.us Phone: 614.644.5422/Fax: 614.887.4021/Pager: 866.591.9954 *************************************************************

1 0

Re: 69/8...this sucks
by Michael.Dillon＠radianz.com 11 Mar '03

11 Mar '03

> 2. Each RIR should operate one or more routers with an open peering > policy which will perform the following functions: I agree that the RIR is the right source for the data but I think that BGP is the wrong protocol for publishing the data. Would you give a BGP feed to all of your customers so that they can inject up-to-date bogons into their firewall configs? Probably not and besides, the enterprise folks wouldn't have a clue what to do with BGP in the first place. That's why I have suggested using LDAP to publish the data. >Apologies if this has been discussed before, but, it seems to me that this >is the easiest way to make the data readily available to the community >directly from the maintainers of the databases in a fashion which is >automatically up to date. At this point a lot if people agree that the data needs to come directly from the database maintainers, in our case that's ARIN. And people also seem to agree that keeping the data automatically up to date is a good thing. We still have some discussion as to which protocol to use for publishing the data. I suggest that what is needed now is to engage ARIN in the discussion and get this on the agenda with them. Technical details can be worked out later, but now we need a commitment from ARIN that they can and will make this data available and keep it up to date. --Michael Dillon

2 1

Re: 69/8...this sucks
by brandon＠rd.bbc.co.uk 11 Mar '03

11 Mar '03

> You want to move things like gtld servers, > yahoo/google (and other 'important' things), including Do a deal with some porn hosters, they get 69.69.69.69 in exchange for advertising tons of free porn there on their next spam run - win/win brandon

5 5

RE: 69/8...this sucks -- Centralizing filtering..
by McBurnett, Jim 11 Mar '03

11 Mar '03

>From Chris Adams: > This isn't meant to be a pick on you (we've got some SWIPs filed > incorrectly that we are working on). I've just run into more and more > cases where ARIN (or other RIR, but I'm typically interested in ARIN > info) info is out of date. Maybe ARIN should periodically > send an "are > you there" type email to contacts (like some mailing lists > do). If that > fails, mail a letter with instructions on how to update your contact > info, and if that fails, delete the invalid contact info - I'd rather > see no contact info than bogus info. > Chris, If you read PPML, there is a HUGE push via Owen DeLong's Policy 2003-1a to help with some aspects of the whois Contact.. his policy is mainly based on the abuse contact, But I think may get extended to all contacts eventually... Owen- Wanta jump in here??? And-- if you feel strong enough to be flamed on the ARIN PPML list propose a Policy based on your comments.. I for one agree with you.. just give 2 or 3 tries.. If it fails once - retry 24 hours if it fails again retry 48 hours. If it fails again.. 3 strikes and your out in the old ball game (add in the music from "take me out to the ballgame") Later, J That's my 10 cents worth- ya know inflation gets us everywhere...

2 1

RE: Move all 9-1-1 to 8-5-5
by McBurnett, Jim 11 Mar '03

11 Mar '03

After working at a CLEC for a while, I must say that I know of very few PBXs that can do this, that the avg customer can afford.. Of course the BIG Lucent Definity series, maybe a few of it's peers.. But the Lucent/AT&T partner/Magix systems, I am nearly positive(99.9%) they can't.. And forget about those 4 line toshiba's..... Anyway that is not a discussion for this list... Jim >-----Original Message----- >From: Mark Segal [mailto:MSegal@FUTUREWAY.CA] >Sent: Tuesday, March 11, 2003 9:04 AM >To: nanog(a)merit.edu >Subject: RE: Move all 9-1-1 to 8-5-5 > > > >> Whenever the North American Numbering Planning Administration >> releases a new toll-free prefix (e.g. 1-800, 1-888, 1-877, >> 1-866) there is always a lengthy delay for individuals >> operating some telephone switches to update their routing >> tables. Its common to be in hotels, and find the hotel PBX >> doesn't recognize a recent toll-free prefix. > >Yes.. But most people don't run translations for all NPA-NXXs >on their 4 >line PBX.... > >Regards, >Mark > >-- >Mark Segal >Director, Data Services >Futureway Communications Inc. >Tel: (905)326-1570 > > >> >> So to "fix" this problem, why don't we move all 9-1-1 numbers >> to the new toll-free prefix, which will break stuff for >> people who don't update their PBX's promptly. When they find >> out they can't report a fire in the hotel because their PBX >> is blocking the new prefix, then they'll fix the PBX. >> >> Let's get real, no one is going to break any "critical" >> resource just for the purpose of making people fix their systems. >> >> >> Rob's bogon lists are good, but unless you have the processes >> in place to keep it update to date (or hire an consulting >> firm to do it for you), its about as useful as putting a list >> of "invalid" phone numbers in your PBX. The lists change all >> the time, and unless you are a full-time LERG expert, it will >> probably get quickly out of date. >> >> Of course, we can always use LDAP to keep all the PBX's updated. >> >

1 0