- Test - lists.nanog.org

Talking about spam and stuff..
by Adrian Chadd 17 Nov '97

17 Nov '97

Hmmsies.. $ cat /tmp/nanoglist | wc -l 2883 $ Ever since I subscribed to the list, I started to get spam. Which is strange, this email accounts gets (a) staff email, (b) nanog email. So a bit of snooping showed me that anyone can send the "who nanog" (or "which nanog", I cant remember which one, I just sent both :-) command to nanog(a)merit.edu and lo and behold, the subscriber list came back. So I'm asking the list admins to please disable the command, so spammers can't just grab a user list.. and also, for people who run large email lists, to consider doing the same. Adrian

5 4

Re: Geographic v. topological address allocation
by Sean Donelan 17 Nov '97

17 Nov '97

>You are confusing transport address (describing a location >in a topology) with an object name (a book, a computer, a >process running on a computer). > >An object name like an ISBN does not need to be >hierarchical because they do not describe discrete >locations. Introducing hierarchy improves managability >and efficiency of databasing. Many hierarchies can be >imposed on object names. If there isn't, there should be a theory in computer science with enough levels of indirection you can solve any problem, i.e. ISBN->Call Number->Shelf Location. Trick question: Does a LC Call number describe a location in a topology or an object name? Many hierarchies can also be imposed on an object's location, especially when that location is connected by a rich topological mesh. >Remember: at each level of naming there can be different >and completely disjoint hierarchies. There are >scalability implications in all of them, most notably when >the names used have size limits or are distributed >non-hierarchically (like ethernet addresses or the COM >domain). However, the important thing is that when a name >is used as a LOCATOR in a topology, in order to be >scalable that name must be related to that topology and in >large networks must lend itself to aggregation in order to >reduce the amount of information needed to have that >locator be used throughout the network. Another axis of the problem is the stability of the names used as locators. Otherwise you have just moved the problem up a level, translating the object name to its instantaneous location. Love that indirection. Propagating the change in object name->locator name when a route flaps, or every corporate merger or acquisition, doesn't scale well any better than the current system. Who is going to tell Bert or Bernie that all those MCI customers need to renumber when they merge their respective networks? Geographic addressing only has the advantages in that continental drift moves at a much slower pace than the changes in most network topologies. How you get to Cleveland might change, but Cleveland tends to remain in the same relative position. However, strict hierarchies have the disadvantage you can wipe out a subtree by simply targeting a higher level node. Being able to wipe out Cleveland by disrupting the Cleveland NAP is not a desirable feature of geographic hierarchical addressing. So you need some redundancy between the subtrees (i.e. a mesh), which means you have to keep track of that redundant information. Since that redundant information is likely based on the providers' facilities in and out of Cleveland, it looks like topological addressing. So do you name objects based on how you get to Cleveland, or based on their presence in Cleveland? But I think everyone has heard this argument before. Trade-offs, trade-offs. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Has spam factory dakotacom.net moved from ACSI to Alternet ?
by Steve Carter 17 Nov '97

17 Nov '97

-----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii > who's announcing 207.201.204.0/255.255.252.0 ? ACSI? Alternet? Both? Here's my traceroute.....It shows dakotacom.net connected by ALTER.net. - -Steve. <snip>#trace dakotacom.net Translating "dakotacom.net"...domain server (<snip>) [OK] Type escape sequence to abort. Tracing the route to dakotacom.net (207.201.204.21) <snip> 3 h1.peer1.wdc1.genuity.net (207.240.1.246) 72 msec 72 msec 68 msec 4 br1.tco1.alter.net (192.41.177.248) 68 msec 72 msec 72 msec 5 111.ATM2-0-0.XR1.TCO1.ALTER.NET (146.188.160.66) [AS 702] 76 msec 80 msec 76 msec 6 193.ATM3-0-0.XR1.DCA1.ALTER.NET (146.188.160.101) [AS 702] 76 msec 72 msec 88 msec 7 100.ATM2-0-0.TR1.DCA1.ALTER.NET (137.39.64.161) [AS 701] 76 msec 72 msec 76 msec 8 101.ATM4-0-0.TR1.EWR1.ALTER.NET (137.39.104.109) [AS 701] 84 msec 108 msec 84 msec 9 100.ATM8-0-0.XR1.EWR1.ALTER.NET (146.188.176.73) [AS 702] 284 msec * * 10 193.ATM11-0-0.GW1.EWR1.ALTER.NET (146.188.176.41) [AS 702] 92 msec 76 msec 84 msec 11 medic-net-gw.customer.ALTER.NET (157.130.97.154) [AS 701] 156 msec 148 msec 156 msec 12 dakotacom.net (207.201.204.21) [AS 8105] 160 msec * 160 msec - -- +-------------------------------------------------------+ | Steve Carter >><< scarter(a)genuity.net | | Network Operations <<>> Phone: (602) 308 2386 | | Genuity Inc. >><< Pager: (800) 394 4957 | | 'An Englishman Abroad' <<>> http://www.genuity,net | +-------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQB1AwUBNHC7lK+UEmo+hvE9AQF9JwL+JlIWryEIA6kLI09nLQMwg/xj09btM2Yu 4rQqnu1XOzEsc9OAQQbujayS8f1XMvYr4b1pmFmWOTNzGADlFXYyUSUV0OYfbvsP Lkhvnfzh+R49XXlx9DLUlrGU0oVxkyIZ =OTE6 -----END PGP SIGNATURE-----

1 0

Re: Has spam factory dakotacom.net moved from ACSI to Alternet ?
by dlr＠bungi.com 17 Nov '97

17 Nov '97

[In the message entitled "Has spam factory dakotacom.net moved from ACSI to Alternet ?" on Nov 17, 16:21, John R Levine writes:] > I've been receiving buckets of spam from dakotacom.net, as many as 90 per > day. They've been connected to ACSI for many months. > > ACSI has a new anti-spam AUP that went into effect today. Today I see that > traceroutes to Dakotacom go through Alternet and > medic-net-gw.customer.ALTER.NET. But the route looks odd, maybe a leak > rather than a new real route. > > I don't speak BGP (my multi-homed ISP does that for me), so can anyone see > who's announcing 207.201.204.0/255.255.252.0 ? ACSI? Alternet? Both? You have to look at the bigger picture. Dakotacom, who I suspect is not quite as innocent as they seem, is trying to distance themselves from gtwinc.com - the source of the spam (207.101.213.0/24). gtwinc.com seems to be off the air at this time. 1 bungi-tlg-gw.sf.tlg.net (140.174.166.37) [AS 3915] 24 msec 16 msec 8 msec 2 bordercore1-hssi0-0.SanFrancisco.mci.net (166.48.13.249) [AS 3563] 16 msec 1 2 msec 12 msec 3 core7.SanFrancisco.mci.net (204.70.4.93) [AS 3561] 264 msec 20 msec 12 msec 4 mae-west3-nap.SanFrancisco.mci.net (204.70.10.246) [AS 3561] 360 msec 52 mse c 56 msec 5 mae-west.acsi.net (198.32.136.79) 44 msec 36 msec 60 msec 6 tucson-az-1-a12-0.acsi.net (206.222.97.8) [AS 6467] 292 msec 320 msec 272 ms ec 7 dakotacom.net.tucson-az-1.acsi.net (206.222.101.238) [AS 6467] 288 msec 44 m sec 48 msec 8 * * * but they do still seem to use dakotacom's gateway. I poked dakota a couple of times, to see if they were still planning on disconnecting them. Hard to say. Dakota is now advertising their space through AS701, and AS8105. * 207.201.192.0/18 192.41.177.108 0 0 6467 i *> 192.41.177.108 0 0 6467 i * 157.130.33.113 50026 0 701 6467 i * i207.201.193.0 157.130.192.97 51123 100 0 701 7079 i *> 157.130.33.113 50032 0 701 7079 i * i207.201.194.0 157.130.192.97 51123 100 0 701 7079 i *> 157.130.33.113 50032 0 701 7079 i * i207.201.200.0/23 198.32.136.79 105 100 0 6467 6983 i * 192.41.177.108 0 6467 6983 i *> 192.41.177.108 0 6467 6983 i * 157.130.33.113 50026 0 701 6467 6983 i * i207.201.204.0/22 157.130.192.97 51119 100 0 701 8105 i *> 157.130.33.113 50021 0 701 8105 i * i207.201.208.0/22 157.130.192.97 51119 100 0 701 8105 i *> 157.130.33.113 50021 0 701 8105 i * i207.201.212.0 157.130.192.97 51119 100 0 701 8105 i *> 157.130.33.113 50021 0 701 8105 i *>i207.201.213.0 207.126.96.3 105 1000 0 7777 i * That's the state of the moment... -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

Re: WorldCom/MCI Merger - Backbone Monopoly?
by Colin "evey" Eve 17 Nov '97

17 Nov '97

I just hope that now they are confirmed to be merging the servers in atlanta and washington which are dropping packets for my connection to icigames.com can be sorted out. Colin. UIN;938778 colineve(a)lodge-house.demon.co.uk http://www.geocities.com/TimesSquare/7985/

1 0

Re: Legal Issues on Blackholeing
by Curtis Brown 17 Nov '97

17 Nov '97

On Nov 17, 10:11am, Paul Flores apparently wrote: > To sum it up: > part of the CDA indicates that "No provider or user of an interactive > computer service shall be treated as the publisher or speaker of any > information provided by another information content provider" > > This woulds seem to indicate that an ISP can not be LEGALLY > held accountable for the content published by a customer. (although > in the case of UBE, I think the means, more so than the message, is > the issue.) I don't think the issue of filtering comes into this at > all. I think (read 'hope') that you are reading too much into this. Going back to non-specific cases regarding the operation and liabilities of running a BBS I shall cite what I feel has been done in the past and seems as if it may remain appropriate: Cases against BBS operators for distributing illegal or offensive material seem to be split, based solely on the level of participation which the operator displays. For those operators that have shown a 'hands off' operational approach, there has been little liability for content. For those operators that take part in creating/managing their content, liability is usually complete. In other words, the way I see this as applicable to ISPs follows: *service* providers which supply TCP/IP access to the internet are liable only to ensure their customers are aware of netiquette. *content* providers (i.e. AOL, MSN...) are fully liable for all content which they manage/distribute. Feedback? cbrown(a)bbnplanet.com Server Administration, GTE Internetworking.

2 1

Re: NAP Solutions
by Sean M. Doran 17 Nov '97

17 Nov '97

Tony Li <tli(a)juniper.net> writes: > A SONET MPLS switch makes for a very interesting > exchange. Yes, for all the reasons you outlined, and because we've been talking about it for a couple years, this what I would deploy in the short run if I were interested in getting large-provider business. Having a circuit per peer has some advantages with respect to failure modes, but is expensive. Assuming that there is still a per bit per second per kilometre cost even for inhouse applications, if a reliable alternative existed, I expect that would be used, particularly as the growth curve of inter-provider traffic necessitates expansion of the private peering circuits. I would hope that people at Sprint, UUWHO (and ANS and MCI) and the various other places using private peering points are thinking about migrating from a "you buy one circuit i will buy one circuit" model to a more general "we will run an exchange point here, you bring circuits to us; you run an exchange point there, we will bring circuits to you, they will be running an exchange point there we will both bring circuits to that" one, although actually making a decision to do this would be dependent on costs and the reliability of new big fast routers and MPLS implementations and interoperability. One fat physical circuit that buys you N peers is probably going to be cheaper than N not-so-fat physical circuits at one peer each, in line costs, manageability and capital expenses (router ports etc.) Of course, the key downside to using a SONET MPLS switch/router is back to scaling. A question for you Tony. What does one do when one has an N port MPLS switch/router and has filled all N ports with traffic? Consider that each of the N ports will become fuller and that there will probably be a desire or requirement for N+1 ports with more to come. The lesson of the Gigaswitches and the ATM counterparts is that scaling beyond a single switch is hard. I don't have an answer, given what I know and can imagine about near-term technology (as opposed to stuff I want you and Crashco to build :) ) > the forseeable future. How long is that these days anyway? Anyway, other than the "what do you do other than give up on port density when you have more traffic or connections than one MPLS switch can handle" concern, I am in complete agreement with you, surprise surprise. Sean.

3 2

Re: Geographic v. topological address allocation
by Sean M. Doran 17 Nov '97

17 Nov '97

Tony Li <tli(a)juniper.net> writes: > An interesting metric might be if the organization's min-cut-set bandwidth > is exceeded by its regional access bandwidth. This is a brilliant idea, but how do you propose to measure the regional access bandwidth, or the even more fun task of determining the total bandwidth so that you can determine the pro rata share due any arbitrary subtree? Sean.

2 1

Re: AGIS Signing up New Spammers
by Leo Bicknell 17 Nov '97

17 Nov '97

In article <64q19v$o1(a)gizmo.dimension.net> you write: >Best guess at ths time, without having had a full review done, is that >filtering spam at the source *might* fall into the same category. However, >since in theory mail is *personal* in nature ratehr than broadcast, it might >be deemed to fall into the same category as blocking all carrier route sorted >bulk mail in the real world. However, note that you *can't* get USPS to do >that, either. The follow your argument wouldn't there be a difference between blocking e-mail from a site (eg, the RBL, or your own sendmail.cf rules) and blackholing an entire site at the IP level? In one case you are acting as an editor claiming that only mail is offensive, in the other you are acting as a service provider preventing damage to your network? It would seem to me that if you argue that the site causes "network problems" and simly toss all of their packets regardless of content you are safer. It is also nastier to the spammer/their provider (eg one or two bad apples render all of AGIS's network unreachable to a great many), which in theory should get better responce to fix the problem. To site an example, no one questions a providers ability to filter a site when it is Smurf'ing them, why not when spamming them? -- Leo Bicknell - bicknell(a)dimension.net Network Engineer - Dimension Enterprises 1-703-709-7500, fax, 1-703-709-7699

2 1

Exchange point Cross-Matrix updated
by Sean Donelan 17 Nov '97

17 Nov '97

I'm sure everyone has been waiting for this. I have updated my Exchange Point Cross-Matrix <http://dranet.dra.com/ExchangeMatrix.html> The matrix consists of 213 listings at 9 exchange points. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2