February 2002 - Test - lists.nanog.org

Re: testing sprint
by measl＠mfn.org 11 Feb '02

11 Feb '02

On Thu, 7 Feb 2002, Christopher A. Woodfield wrote: > Sprint, to date, hasn't the balls to terminate ANYONE for spamming outside of > dialup users, IIRC. They terminate dial users for abuse now? When did _that_ start? Sprint is the only place where I can *count* on seeing accounts whacked for abuse doing the Gypsy Dance for years to come, even (especially) if they haven't "reformed". -- Yours, J.A. Terranson sysadmin(a)mfn.org If Governments really want us to behave like civilized human beings, they should give serious consideration towards setting a better example: Ruling by force, rather than consensus; the unrestrained application of unjust laws (which the victim-populations were never allowed input on in the first place); the State policy of justice only for the rich and elected; the intentional abuse and occassionally destruction of entire populations merely to distract an already apathetic and numb electorate... This type of demogoguery must surely wipe out the fascist United States as surely as it wiped out the fascist Union of Soviet Socialist Republics. The views expressed here are mine, and NOT those of my employers, associates, or others. Besides, if it *were* the opinion of all of those people, I doubt there would be a problem to bitch about in the first place... --------------------------------------------------------------------

1 0

Re: Reducing Usenet Bandwidth
by Michael Painter 11 Feb '02

11 Feb '02

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." [40 more lines snipped] ----- Original Message ----- From: "Stephen Stuart" <stuart(a)tech.org> To: "Vadim Antonov" <avg(a)exigengroup.com> Cc: <nanog(a)merit.edu> Sent: Friday, February 08, 2002 1:45 PM Subject: Re: Reducing Usenet Bandwidth > > > What USENET needs is a distributed system for collection of per-article > > and per-sender ratings, and for filtration based on those ratings. That > > would be useful for other applications, as well :) > > 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. > > It would almost be like gluing a USENET distribution front-end onto a > collection of Napster back-ends. > > Stephen >

1 0

Re: Ethernet EP - MAC Address Filtering
by David McGaugh 11 Feb '02

11 Feb '02

This is a multi-part message in MIME format. --------------7DFBF929699F5DC9E36CC8F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Actually, I was more speaking in terms of applying the filters to your router port as an Exchange Point Member to prevent another unscrupulous exchange point member from default routing you or other things nasty. -Dave Deepak Jain wrote: > > -----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 --------------7DFBF929699F5DC9E36CC8F2 Content-Type: text/x-vcard; charset=us-ascii; name="david_mcgaugh.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dave McGaugh Content-Disposition: attachment; filename="david_mcgaugh.vcf" begin:vcard n:McGaugh;David tel;fax:360.816.3297 tel;work:360.816.3718 x-mozilla-html:FALSE url:http://www.eli.net org:Electric Lightwave, Inc.;Network Planning and Engineering adr:;;4400 NE 77th Ave.;Vancouver;WA;98662;USA version:2.1 email;internet:dmcgaugh@eli.net title:Internetwork Engineer x-mozilla-cpt:;26448 fn:David McGaugh end:vcard --------------7DFBF929699F5DC9E36CC8F2--

1 0

"Tier 1 Backbones" which don't filter IP packets? --SUMMARY
by Ehud Gavron 11 Feb '02

11 Feb '02

This is a cryptographically signed message in MIME format. --------------ms8E9148111FF1C6380496B39C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On January 27th, while pimping the latest NANOG Traceroute at ftp://ftp.login.com/pub/software/traceroute/beta I asked about providers that don't administratively prohibit LSRR and SSRR packets. Response was overwhelming, and I've finally gone through all the responses. Requests for summary were overwhelming, and I've BCCd all of those who requested that, but thought I'd CC the list since there's such interest. Thanks for all the feedback, especially those who took the time to provide official responses from the various corporations... and I'm sorry I couldn't respond to everyone individually. Ehud LSRR and SSRR SUMMARY: Some providers REQUIRE it for peering. Lots of providers ALLOW it from customers and peers. Only one was verified to deny LSRR/SSRR and admit to it. There is a good work in progress page at http://www.gweep.net/~crimson/networks/lsrr.html REQUIRE: (alpha order) Genuity [verified] RCN [from URL above] ViaNet [from URL above] Verio [verified] WiscNet [from URL above] ALLOW: Cable & Wireless Sprintlink Global Crossing Hurricane Networks E.Spire Worldcom AT&T DO NOT ALLOW AND ADMIT TO IT: Time Warner Telecom [verified] -end- --------------ms8E9148111FF1C6380496B39C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH3AYJKoZIhvcNAQcCoIIHzTCCB8kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Ba8wggJ+MIIB56ADAgECAgMFM4gwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA3MTAwMjQ0NDBaFw0wMjA3MTAwMjQ0NDBa MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmdh dnJvbkB3ZXR3b3JrLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAz8GDRre6PkGw 8KDCAFOQMgiT/h8rx7OmiYOfhEArmB8zuLovZjGy74+IDlJQTpy78rlMLx/9ATmOnTExdCYR khFUsenIyE35OyXWpFZuXMV64U+KmE1c22DFYUGtmUGEIejLpVyUSxVbscGk5OleUCP4Pwm7 7ay8qO+XsoeGuGUCAwEAAaMvMC0wHQYDVR0RBBYwFIESZ2F2cm9uQHdldHdvcmsubmV0MAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAUXEsS8JRAedcxYuz9Rfm/FDYA/mKIAwr VhpbBhI8PwoGweTI3TtPck8c6iejwTGKvJzl69vZYszCeVOER8YIZQ8d6a3lOneJU5eSNH9Z GiEts5Kev3V8VFJcIxhcnHSLs3i25x4dOLFK7Q2+JFCzzICx8pnHd07LmIk0sY5mwg0wggMp MIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5 WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2Vz MSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K73 7nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzp q+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREE IjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27 j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBv Lli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gx ggH1MIIB8QIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmlj YXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw AgMFM4gwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMjAyMDgxODA4NTBaMCMGCSqGSIb3DQEJBDEWBBRXzdA8wXVJeuDcmlfxK0gB G5jLszBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgJEb KEfQ8bu9NFBR0zMToG7E7VjQfuwHHz6OLoWOoBLwQhXYwiAAvPyQlYNfIdjZupujRYd51A4J Q02yPr8/mIkbgshdDKmRs1Ngi8Q0m73rdH1vhzKTmvsSUi/OynMUdbqFIXb67jerQhsYHSwK FDPCr1mLcMz/VXCX8Vb01Uuo --------------ms8E9148111FF1C6380496B39C--

1 0

Re: testing sprint
by Christopher A. Woodfield 11 Feb '02

11 Feb '02

Sprint, to date, hasn't the balls to terminate ANYONE for spamming outside of dialup users, IIRC. -C On Wed, Feb 06, 2002 at 08:14:34PM -0600, Eric A. Hall wrote: > > > The question is, does sprint.net have the balls to terminate Sprint long > distance for spamming? > > http://tracking.networkpromotion.com/Tracking/etags.html?LinkID=5202 > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- --------------------------- Christopher A. Woodfield rekoil(a)semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B

1 0

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

11 Feb '02

USENET is by its nature a commons facility for sharing rivalrous resources (e.g. bandwidth and storage capacity). 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 lacking usage control mechanisms such commons are doomed to disintegrate. No exceptions were found so far. (Such control mechanisms do not have to be market-based to be effective and successful; public policy or code may embed usage controls as well - TCP's cooperative congestion control is an excellent example). When the Internet was small, the personal reputation was strong enough limiter to abuse of shared resources. It only works when community is smallish and elitary. This is clearly no longer the case. In other words - USENET cannot be fixed with technological improvements as long as the root problem (admission control) is not solved. Improving transmission or storage systems would only let spammers to send more spam for free. Therefore, 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 for primary functions. 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. Correspondingly, though most backbone (and some access) IP routing equipment already has everything needed to implement community TOS, they 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

Re: Reducing Usenet Bandwidth
by R.P. Aditya 11 Feb '02

11 Feb '02

On Fri, Feb 08, 2002 at 10:09:12PM -0800, Stephen Stuart wrote: > The topic being discussed is to try to reduce USENET bandwidth. One > way to do that is to pass pointers around instead of complete > articles. If the USENET distribution system passed pointers to Just to chime in, the idea of passing pointers around has come up in several different versions over the last so many years and combined with pre-fetching/caching seems like a very good idea; it's a pity that no one has really tried it given that many of the tools already exist (disclaimer: I've been dabbling with writing something using existing protocols on and off for some time). So far, and this was inspired by the loss of a clariNet newsfeed, I've written a silly little personal nntp server based on an SQL back-end that collects RSS pointers to website "articles". The server stores the "pointers" (URLs) and retrieves the article directly from the remote webserver (or local http cache) on demand (currently spits out html, ugh). The header info (overview) is composed of the RSS data (unfortunately quite sparse in most cases) and the "headline" fetcher script builds a "score" for each article based on my predefined criteria. I've found at least one mailing list archive that produces RSS files for each mailing list that can be simliarly used to populate a "newsgroup". So mailing lists provide a simple way of creating a "publishing" method other than a website. In all these cases, "replying" to a message is a bit involved, but not impossible. So, as far as I can tell, all the tools exist to implement a new set of newsgroups based on existing protocols that don't involve the massive bit movement of Usenet however preserve the highly efficient news reading mechanisms of news readers. Anyone have a sample, open-source, robust NNTP server implemented in Java or perl that needs a SQL backend and article population mechanism? Adi

1 0

RE: zebra/ospf issue
by Mark Radabaugh 11 Feb '02

11 Feb '02

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Josh Gentry > Sent: Friday, February 08, 2002 1:38 AM > To: nanog(a)merit.edu > Subject: zebra/ospf issue > > > > Folks, > > I'm experimenting with using Zebra running on a Debian box to > do OSPF with > the Ciscos on our network. The zebra box has 2 interfaces, each in a > different area. This is the first time we have tried to impliment > multiple areas on our network. Right now, area 51 consists > only of the > zebra box and a Cisco 2500, and is just for testing. > > The zebra box is forming a full adjacency with the Cisco in > area 51 with > no problems. It will not, however, become fully adjacent > with the DR and > BDR in area 0. This seems to be preventing the distrobution I think this is normal behavior (without really analyzing things...). See if this helps any: http://www.cisco.com/warp/customer/104/11.html Mark Radabaugh

1 0

Re: Reducing Usenet Bandwidth
by Michael Painter 11 Feb '02

11 Feb '02

>>If 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.<< Hmm, reminds me of the Compu$erve Forums, which, ironically, met their demise (imho) when the WWW (and Usenet) started to blossom. ex 70720,151 ----- Original Message ----- From: "David Schwartz" <davids(a)webmaster.com> To: "Stephen Stuart" <stuart(a)tech.org>; <nanog(a)merit.edu> Sent: Friday, February 08, 2002 3:32 PM Subject: Re: Reducing Usenet Bandwidth > > > >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. > > Like 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. > > Does it make sense for the New York Times to pay me to read it? But perhaps > it does for the Weekly Advertiser. > > The 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. > > If 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. > > DS > >

1 0

Re: Querying Large Number of Whois Records?
by David Charlap 11 Feb '02

11 Feb '02

Spencer.Wood(a)dot.state.oh.us wrote: > > We are wanting a way to go though our web servers logs, and try to > get a idea of where our traffic is coming from...... > > We have a script that works really great, but we have to put a pause > in it to keep from overloading ARIN... If you are trying to determine the corporate entities your connections are coming from (e.g. AOL, vs. Earthlink, vs. Microsoft, etc....), this might work. If you are trying to determine geographic location, you will find this method frought with errors. For instance, the address block I'm sending this message from is registered to FORE Systems in Warrendale, PA. But I am actually in a remote office (Vienna, VA), connected to Warrendale via a corporate leased-line. We also have offices in foreign countries which may use addresses from the same netblock, so even localizing the connection to a nationality may not work. Of course, even if you get the information you want, you are still assuming that the WHOIS database is accurate, which is not always true. -- David

1 0