- NANOG - lists.nanog.org

hmm
by jlewis＠lewis.org 12 Feb '02

12 Feb '02

Errors-To: owner-nanog-outgoing(a)merit.edu Should that have been Errors-From: owner-nanog-outgoing(a)merit.edu ? -- ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ---------- Forwarded message ---------- Return-Path: <MAILER-DAEMON(a)redhat1.mmaero.com> Received: from mailhost.mmaero.com (mailhost.mmaero.com [208.152.224.3]) by redhat1.mmaero.com (8.11.6/8.9.3) with ESMTP id g1C3On726998 for <jlewis(a)redhat1.mmaero.com>; Mon, 11 Feb 2002 22:24:49 -0500 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by mailhost.mmaero.com (8.11.2/8.11.2) with ESMTP id g1C3OnY13695 for <jlewis(a)lewis.org>; Mon, 11 Feb 2002 22:24:49 -0500 Received: by segue.merit.edu (Postfix) via BOUNCE id 10C015DDC4; Mon, 11 Feb 2002 22:24:49 -0500 (EST) Date: Mon, 11 Feb 2002 22:24:49 -0500 (EST) From: MAILER-DAEMON(a)merit.edu (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: jlewis(a)lewis.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6152D5DD97.1013484289/segue.merit.edu" Message-Id: <20020212032449.10C015DDC4(a)segue.merit.edu> This is the Postfix program at host segue.merit.edu. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please contact <postmaster(a)merit.edu> If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program <owner-nanog-outgoing(a)merit.edu>: unknown user: "owner-nanog-outgoing"

1 0

While the cat is away, the mice will play
by jlewis＠lewis.org 12 Feb '02

12 Feb '02

It seems someone from bestweb.net is rebroadcasting several day old nanog posts back to the list. I've gotten more than a dozen just now, and they're still coming in. They're also generating new message ids, so my dupe filter isn't catching them. -- ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ---------- Forwarded message ---------- Return-Path: <owner-nanog(a)merit.edu> Received: from mailhost.mmaero.com (mailhost.mmaero.com [208.152.224.3]) by redhat1.mmaero.com (8.11.6/8.9.3) with ESMTP id g1C3JZ726973 for <jlewis(a)redhat1.mmaero.com>; Mon, 11 Feb 2002 22:19:35 -0500 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by mailhost.mmaero.com (8.11.2/8.11.2) with ESMTP id g1C3JUY13667 for <jlewis(a)lewis.org>; Mon, 11 Feb 2002 22:19:30 -0500 Received: by trapdoor.merit.edu (Postfix) id 22AF691317; Mon, 11 Feb 2002 21:45:34 -0500 (EST) Delivered-To: nanog-outgoing(a)trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FF03912CE; Mon, 11 Feb 2002 21:24:04 -0500 (EST) Delivered-To: nanog(a)trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8AB591273 for <nanog(a)trapdoor.merit.edu>; Mon, 11 Feb 2002 21:16:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 83D395DDA5; Mon, 11 Feb 2002 21:16:55 -0500 (EST) Delivered-To: nanog(a)merit.edu Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by segue.merit.edu (Postfix) with ESMTP id 5B3F95DD92 for <nanog(a)merit.edu>; Mon, 11 Feb 2002 21:16:55 -0500 (EST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 9EB762317F; Mon, 11 Feb 2002 21:17:11 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 61CB39EFBC; Mon, 11 Feb 2002 21:12:09 -0500 (EST) Reply-To: <deepak(a)ai.net> From: "Deepak Jain" <deepak(a)ai.net> To: "David McGaugh" <david_mcgaugh(a)eli.net>, <nanog(a)merit.edu> Subject: RE: Ethernet EP - MAC Address Filtering Date: Fri, 8 Feb 2002 15:50:02 -0500 Message-Id: <20020212021209.61CB39EFBC(a)okeeffe.bestweb.net> Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing(a)merit.edu X-Loop: nanog -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of David McGaugh Sent: Friday, February 08, 2002 3:18 PM To: nanog(a)merit.edu Subject: Ethernet EP - MAC Address Filtering Just curious if anyone is performing MAC Address Filtering at any of the Ethernet Exchange Points. If so has it been found to be easy to administer or difficult where by peers may be changing Layer 3 devices or Interfaces without notice? Alternately is MAC Address Filtering considered an unneeded security measure? Thanks, Dave ---- Speaking of this, is MAC Address filtering [at an IX] really designed to eliminate the possibility of new hardware showing up on the port or is it more the idea of keeping lots of boxes from showing up directly [like hanging another switch off the port]. If its the latter, a seemingly sensible approach would be to limit the number of unique MAC addresses to like 2-4 per port. This way you can change your equipment without prior notice, but you can't (as easily) violate the integrity of the switching fabric. I know for our network ports we limit to no more than 2 unique MACs in a certain time period [~5 minutes or so] which again, allows swapping of equipment without compromising anything that MAC layer filtering is supposed to protect. Deepak Jain AiNET

1 0

Releasing AS numbers for misconfigured nets
by Avleen Vig 12 Feb '02

12 Feb '02

I hope I don't spark off a huge discussion on this :-) But having said that, I am looking for personal as well as professional opinions. This email is being posted to both RIPE-EOF and NANOG as the decision could be helpful to both parties, not just those in the RIPE region. Background: A many weeks ago, SAFE (http://www.ircnetops.org/smurf) to the decision not to release the IP addresses of smurf amplifiers, only the weekly statistics on smurf amplifiers in RIPE IP space as a whole. This was to partly protect the misconfigured networks from being abused at a time when they may not be able to fix the problem immediately. Now: A number of requests have been made for SAFE to release the AS number of unco-operative[1] large (x500+ reply) smurf amplifiers, so that ISP's can filter these people out more easily. Further requests have been made that the AS numbers for *all* large smurf amplifiers be released weekly. What are the different thoughts people have on this? Kindest regards, [1] = those who fail to close an open smurf amplifier by the third check. Checks are performed weekly. Notifications are emails to 'abuse', 'tech-c' and 'admin-c' contacts as listed in the RIPE WHOIS database. -- Avleen Vig Network Security Officer Smurf Amplifier Finding Executive: http://www.ircnetops.org/smurf

1 0

bgp misconfiguration study
by Ratul Mahajan 12 Feb '02

12 Feb '02

some of you might be aware of the bgp misconfiguration study being done at the university of washington -- http://www.cs.washington.edu/homes/ratul/bgp/index.html we recently finished a paper, which is available at http://www.cs.washington.edu/homes/ratul/bgp/bgp-misconfigs.ps comments welcome. -- ratul

1 0

Re: Reducing Usenet Bandwidth
by Vadim Antonov 12 Feb '02

12 Feb '02

USENET is by its nature a commons facility for sharing rivalrous resources (e.g. bandwidth and storage capacity). Some elementary reasoning (if anyone's interested, Lawrence Lessig's "The Future of Ideas" contains as detailed discussion as anyone can bear :) leads to the conclusion that such commons lacking usage control mechanisms are doomed to disintegrate. No exceptions to this rule were found so far. (The usage control mechanisms do not have to be market-based to be effective and successful; public policy or code may embed usage controls as well - the cooperative congestion control in TCP is an excellent example). When the Internet was small, personal reputation was strong enough limiter to abuse of these shared resources. Howevber, it only works when a community is smallish and elitary. It is clearly no longer the case with USENET. In other words - USENET cannot be fixed with technological improvements as long as the root problem (lack of admission control) is not solved. Improving transmission or storage systems would only let spammers to push more spam for free (and to reduce S/N ratio even further). I'd say it is time to declare USENET defunct. It was fun while it lasted. --vadim PS: Talking about commons... A lot of network and computing resources are quite under-utilized. Many owners of those resources would be quite willing to donate underused capacity to the community - providing that such donation will not have any noticeable negative impact on resources' performance on primary tasks. While most modern OS-es have mostly adequate prioritization mechanisms, a lot of would-be donors are turned out by the effective inability to protect their primary network capacity. Therefore, i would like to ask ISPs to be civic-minded and standartize on an IP TOS for "community" traffic, giving normal IP traffic an absolute queueing and drop-policy preference over packets with community TOS. Most backbone (and some access) IP routing equipment already has everything needed to implement community TOS, the equipment vendors could be similarly civic-minded by making such preference turned on by default and by improving per-TOS utilization data collection, so NMS-es won't cry wolf seeing links being highly utilized by low-priority traffic. Another area which needs improvement is making L2 switches similarly aware of community TOS in IP packets.

1 0

C&W Engineering
by German Martinez 12 Feb '02

12 Feb '02

Hi, Somebody from C&W Engineering that can contact me off-line Thank you German ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * THE DILBERT FUTURE * * Thriving on Stupidity in the 21st Century * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Internet capacity will increase indefinitely to keep up with the egos of the people using it"

1 0

The Cidr Report
by CIDR Report 12 Feb '02

12 Feb '02

This is an auto-generated mail on Fri Feb 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 08Feb02 0) General Status Table History ------------- Date Prefixes 010202 105568 020202 105595 030202 105578 040202 105667 050202 105600 060202 105584 070202 105721 080202 105598 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 96.0.0.0/20 from AS3549 AS Summary ---------- Number of ASes in routing system: 12381 Number of ASes announcing only one prefix: 7537 (4280 cidr, 3257 classful) Largest number of cidr routes: 717 announced by AS701 Largest number of classful routes: 1357 announced by AS701 1) Gains by aggregating at the origin AS level --- 08Feb02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1156 892 264 22.8% Telstra Pty Ltd AS701 1357 1126 231 17.0% UUNET Technologies, Inc. AS577 323 197 126 39.0% Bell Advanced Communications Inc. AS16473 198 77 121 61.1% Bell South AS7018 821 703 118 14.4% AT&T AS4151 261 149 112 42.9% USDA AS6595 168 60 108 64.3% DoD Education Activity Network As AS17557 195 88 107 54.9% Pakistan Telecom AS705 293 189 104 35.5% UUNET Technologies, Inc. AS852 425 325 100 23.5% Telus Advanced Communications AS7046 329 230 99 30.1% UUNET Technologies, Inc. AS19632 94 9 85 90.4% Metropolis Intercom S.A. AS2048 185 105 80 43.2% State of Louisiana AS12302 110 31 79 71.8% MobiFon S.A. AS1239 475 398 77 16.2% Sprint AS4755 221 150 71 32.1% Videsh Sanchar Nigam Ltd. Autonom AS4323 406 340 66 16.3% Time Warner Communications, Inc. AS703 279 217 62 22.2% UUNET Technologies, Inc. AS3464 157 97 60 38.2% Alabama SuperComputer Network AS7303 107 49 58 54.2% Telecom Argentina Stet-France Tel AS724 209 151 58 27.8% DLA Systems Automation Center AS16758 63 6 57 90.5% IKON Office Solutions AS3908 320 264 56 17.5% Supernet, Inc. AS226 145 89 56 38.6% Los Nettos AS13999 70 14 56 80.0% Mega Cable S.A. de C.V. AS19834 63 8 55 87.3% NetForce, Inc. AS702 654 600 54 8.3% UUNET Technologies, Inc. AS1 491 438 53 10.8% BBN Planet AS2149 308 256 52 16.9% Performance Systems, Inc. AS9051 73 22 51 69.9% INCONET Autonomous System Total 53855 42131 11724 21.8% 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: Reducing Usenet Bandwidth
by Steven M. Bellovin 12 Feb '02

12 Feb '02

In message <00e801c1b0fe$e15f8580$0100007f(a)flex.com>, "Michael Painter" writes: > >Kinda' off topic, but I've seen this gibberish in many spam posts to usenet >groups. What purpose does it serve? > >Thanks, > >--Michael > > >"She may will virtually cook above Ron when the sticky wrinkles >nibble with the sharp river. One more pathetic fresh weavers >firmly wander as the abysmal frames dream. > >Why will you reject the sweet deep tags before Priscilla does? > >Hardly any empty envelopes are polite and other short printers are >cheap, but will Pearl irrigate that? She'd rather cover eventually than >scold with Ophelia's fat dose. > >Are you kind, I mean, arriving without handsome candles? He might >judge the difficult sauce and explain it in front of its light. >Every proud dryers dye Jay, and they wistfully receive Elisa too. Get your >easily climbing ball inside my mirror. You won't help me recommending >outside your smart monument. Some forks fear, excuse, and taste. Others >angrily sow." > Some spammers add random gibberish to foil assorted anti-spam techniques. If this gibberish is different than the gibberish the same ad has in another newsgroup, it will appear to be a different post, and won't be canceled. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

1 0

The Great RADB Clean-Up
by Christerfer R. Frazier 12 Feb '02

12 Feb '02

Effective April 2, 2002, Merit Network, Inc. will begin the process of removing RADB maintainer objects that have not been renewed and paid for 2002. This message is to inform the community about our clean-up process so that RADB users can take measures to minimize any operational impact. All maintainers scheduled for removal will be posted before March 15, 2002 at http://www.radb.net/docs/deletelist.html. Currently, about 2,100 maintainers with 52,000 total objects are unpaid and scheduled for removal beginning April 2 unless payment is made. Of the total 2,100 maintainers, 1,100 have associated valid objects in the RADB. These 1,100 maintainers, in turn, have 22,000 associated valid objects that are currently being routed in the Internet. For example, eleven of the top twenty maintainers (in terms of number of total objects) have not yet been renewed and are scheduled for removal. We are currently making a targeted effort to remind the owners of maintainers with valid objects about the deadline. About 1,000 "stale" maintainers with either invalid objects or no objects at all will be removed as part of the clean-up. All maintainer IDs scheduled for removal will be posted on the RADB Clean-up web page at http://www.radb.net/docs/deletelist.html before March 15, 2002. As of today, only some of the maintainers have been posted. At the same URL, you will also find a tool to check for a specific maintainer and associated objects (if any) targeted for removal. If you are filtering routes based on the RADB, we urge you to stay abreast of this information. We will be providing regular updates via the NANOG list and on the web page. The RADB service fee for January 1, 2002 through December 31, 2002 is $250 per maintainer object. The RADB service agreement must be renewed annually. Merit's policy, as specified in the agreement, is to remove maintainers that have not been renewed and paid. As a non-profit organization, Merit does not pursue profit as a goal. The $250 maintainer fee is strictly a cost recovery mechanism that helps support the ongoing 24x7 operations of the RADB. Costs that Merit must cover through maintainer fees include contracting for 24x7 NOC monitoring; server maintenance and connectivity; help-desk support; second-level 24x7 on-call engineering; and maintenance of the IRRd database server software that powers the RADB. We welcome your input on the RADB clean-up. The Merit RADB team will be on hand to discuss questions and concerns about the database clean-up during the Route Registry BOF at NANOG24 on Monday, 9:00-10:30 PM. We hope you'll join us! URLS: To view or query the list of maintainer IDs scheduled for removal: http://www.radb.net/docs/deletelist.html To review the RADB maintainer object agreement: http://www.radb.net/docs/agreement.html To renew RADB service and pay for your maintainer object: https://www.merit.edu/cgi-bin/radb/pay/alive For general information: http://www.radb.net For Merit RADB, Chris Frazier

1 0

Re: Reducing Usenet Bandwidth
by David Schwartz 12 Feb '02

12 Feb '02

>I would argue that what USENET needs is a way for the cost of >publication to be incurred by the publisher; storing the data in= your >own repository (or repositories) while pointers get flooded= through >the USENET distribution system would give publishers an= incentive to >do garbage collection that they do not have today. =09Like many Internet settlement schemes, this seems to not make= much sense. If a person reads USENET for many years enjoying all of its wisdom,= why should he get a free ride? And why should the people who supply that= wisdom have to pay to do so? A USENET transaction is presumed to benefit both= parties, or else they wouldn't have configured their computers to make that= transaction. =09Does it make sense for the New York Times to pay me to read it?= But perhaps it does for the Weekly Advertiser. =09The reason that automated schemes such as "publisher pays" will= fail is because determining who "should" pay is too complex for automated= schemes. You will just push around who takes advantage of who. =09If you ask a question, you should pay. If I provide you with= useful help, you should pay. If I suggest a commercial solution to your= problem, who should pay? If I harass you for not knowing the answer to the= question, I should pay. =09DS

1 0