- NANOG - lists.nanog.org

freeipdb - experiences?
by Christian Kuhtz 11 Mar '02

11 Mar '02

anyone around here using it in an sp environment? care to share your experiences? personal reply is fine, i'll summarize. thanks, chris (yes, i'm aware of the freeipdb mailing lists)

1 0

Problems with a black hole list in the netherlands
by Richard Irving 10 Mar '02

10 Mar '02

Hello, we are currently having a problem with a vigilante block list in the netherlands... I figure this is as good a forum as any.... >The boilerplate: >Please see <http://selwerd.cx/xbl/>, xbl is a *local* list, it would cost >us time to check whether we can whitelist your IP. Upon contacting this individual we get: >I listed the netblock(s) of your ISP because we get spam and >autoreplies from it and sometimes, if at all, mail that is readworthy. Of course, he can't produce -any- spam, or autoreply's, from our range.. or much of anything, really. Probably hit by a NIMBDA worm, or something. But, he has one of those "Unix Admin from H-ll" attitude's. Unprofessional, and Vigilante. How would one approach -this- ? I would ignore the fool, but his list is mentioned at Relays.OsiruSoft.com.... and some consider them as a valid source of data.... * sigh * Idea's ?

5 8

The Cidr Report
by CIDR Report 09 Mar '02

09 Mar '02

This is an auto-generated mail on Fri Mar 8 23:00:00 PST 2002 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 08Mar02 0) General Status Table History ------------- Date Prefixes 010302 106896 020302 107000 030302 107010 040302 107088 050302 107144 060302 107315 070302 107121 080302 107198 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 10.1.1.1/32 from AS(65301) *** Bogus 96.0.0.0/20 from AS3549 AS Summary ---------- Number of ASes in routing system: 12561 Number of ASes announcing only one prefix: 7642 (4326 cidr, 3316 classful) Largest number of cidr routes: 747 announced by AS701 Largest number of classful routes: 1399 announced by AS701 1) Gains by aggregating at the origin AS level --- 08Mar02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1399 1135 264 18.9% UUNET Technologies, Inc. AS1221 1137 880 257 22.6% Telstra Pty Ltd AS17557 232 98 134 57.8% Pakistan Telecom AS16473 198 77 121 61.1% Bell South AS7018 803 685 118 14.7% AT&T AS6595 174 60 114 65.5% DoD Education Activity Network As AS852 445 334 111 24.9% Telus Advanced Communications AS4151 254 149 105 41.3% USDA AS705 303 200 103 34.0% UUNET Technologies, Inc. AS7046 348 246 102 29.3% UUNET Technologies, Inc. AS577 291 195 96 33.0% Bell Advanced Communications Inc. AS19632 94 9 85 90.4% Metropolis Intercom S.A. AS2048 185 105 80 43.2% State of Louisiana AS12302 114 35 79 69.3% MobiFon S.A. AS9051 100 24 76 76.0% INCONET Autonomous System AS4323 422 347 75 17.8% Time Warner Communications, Inc. AS4755 219 146 73 33.3% Videsh Sanchar Nigam Ltd. Autonom AS1239 485 413 72 14.8% Sprint AS7303 118 53 65 55.1% Telecom Argentina Stet-France Tel AS3908 329 264 65 19.8% Supernet, Inc. AS16814 78 16 62 79.5% NSS, S.A. AS3464 157 97 60 38.2% Alabama SuperComputer Network AS724 214 156 58 27.1% DLA Systems Automation Center AS10620 79 21 58 73.4% TVCABLE BOGOTA AS1 478 420 58 12.1% BBN Planet AS16758 63 6 57 90.5% IKON Office Solutions AS19834 63 8 55 87.3% NetForce, Inc. AS702 592 539 53 9.0% UUNET Technologies, Inc. AS226 144 91 53 36.8% Los Nettos AS209 307 254 53 17.3% Qwest Total 54046 42027 12019 22.2% For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

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

08 Mar '02

In message <Pine.GSO.4.33.0203061459240.3098-100000(a)rampart.argfrp.us.uu.net>, "Christopher L. Morrow" writes: > >On Wed, 6 Mar 2002, Ron da Silva wrote: > >> >> On Wed, Mar 06, 2002 at 09:41:55AM -0500, Steven M. Bellovin wrote: >> > >> > In message <gu9ofi1rcwe.fsf(a)rampart.argfrp.us.uu.net>, Eric Brandwine writ >es: >> > >> > > >> > >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. > >There is no need to drop traffic for things that aren't listening. Eric's >point was you deploy your fancy-dan mail server with ONLY 22 and 25 >listening, you know that's all that's listening and your >daily/hourly/weekly/monthly automated audits tell you this continually and >alert when there are problems/deviations. So, why filter anything in this >case? It's wasted bandwidth/processing power. > I was agreeing with Eric's point. I've been saying this for years. My comment about the packet filter was to deal with services that are needed for some internal purposes, but for some reason can't protect themselves. Right now, that's snmp -- you may have snmpd running on your mail server, but given the recent CERT advisory you need to keep the bad guys away from it. (Yes, you should install fixed code -- but given how many components were affected by that advisory, it's quite obvious that no one has had time to test the fixes properly.) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

5 8

black hat .cn networks
by Dan Hollis 08 Mar '02

08 Mar '02

http://wired.com/news/politics/0,1283,43437,00.html Time to drop AS4134. -Dan

16 17

Equinix Exchange Point
by Guy.Ram＠usa.telekom.de 08 Mar '02

08 Mar '02

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

7 8

Frame Relay Aggregation Experience
by Tim McKee 08 Mar '02

08 Mar '02

With the quantity of equipment vendors that have bitten the dust over the lat year, I would like to update my database of who still exists and what products they have in the small and medium size frame aggregation product (for remote ILEC colo deployment) with ATM IMA and DS3 delivery. Also small ATM switches with IMA, DS3 and OC3c concentration capabilities. I would appreciate any real operational comments regarding this type of equipment. I will gladly summarize the information and comments and place it online for general access by the NANOG community. Thanks in advance, Tim McKee

1 0

Equinix Exchange Point
by Louisa_Coughlan＠rcn.net 07 Mar '02

07 Mar '02

RCN will be there in about a week. -lou

1 0

Re: Telco's write best practices for packet switching networks
by JC Dill 07 Mar '02

07 Mar '02

On 04:37 PM 3/7/2002 -0500, Sean Donelan wrote: >My comment was originally prompted by the meeting minutes which >reported on the survey data showing that 100% of carriers are implementing >firewalls in their gateways. The 100% is what caught my eye. Is that "100% of carriers report implementing firewalls in 100% of their gateways" or "100% of carriers report implementing firewalls in at least one gateway"? I suspect that it's closer to the later than the former, and that it includes firewalls located at gateways on the *customer* side of the circuit (managed IP services, including managing customer routers and firewalls). jc

1 0

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

07 Mar '02

In message <Pine.GSO.4.40.0203071618090.25551-100000(a)clifden.donelan.com>, Sean Donelan writes: > >My comment was originally prompted by the meeting minutes which >reported on the survey data showing that 100% of carriers are implementing >firewalls in their gateways. The 100% is what caught my eye. As the >topic comes up in various places, large ISPs repeatedly say they are >unable to implement filters or packet screening on their high-speed >links such as at peering points. So the self-reported 100% implementation >of screening and filtering firewalls at gateways didn't seem to jive >with my understanding of the limitations faced by large ISPs. Yup. > >Firewalls can be a useful tool in the security engineer's toolbox. But >they get misused a lot. I don't believe security engineers are better >programmers. If there was a class of programmers in the world that didn't >make mistakes, I would hire them to write the applications. When the >firewall is more complex than the application server it is "protecting" >which is likely to have more mistakes? > Yes and no. I don't think that security programmers are any better than application programmers. But they might be trained differently. For example, I suspect that most application programmers have never heard of format string vulnerabilities. I would hope that most security professionals have. But you're absolutely right about the complexity of many of today's firewalls -- I've been complaining about that for years. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

1 0