May 1997 - Test - lists.nanog.org

TUTORIAL INFO
by Pam Ciesla 15 May '97

15 May '97

The ISP Tutorial scheduled for Wednesday, June 4th in Tampa, FL will be held at the Hyatt Regency Westshore in the Regency Ball Room. The tutorial will be 7:30-9:00PM. This is the evening preceding the NANOG Meeting which will take place in the same location. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

Re[2]: Who Are The Good Guys?
by ptripp＠equinox.COM 15 May '97

15 May '97

Clueless is the operative word. Bet whoever sent you that message dropped (or was thrown) out of law school and is that sophomoric stage of learning about computers and 'the net' where their 'Big Brother' complex shines through. Philip R. Tripp Voice: (954) 746-9000 Ext.236 Equinox Systems Inc. Fax: (954) 746-8378 Technical Support WWW: http://www.equinox.com One Equinox Way FTP: ftp://ftp.equinox.com Sunrise, FL 33351-6709 E-Mail: ptripp(a)equinox.com Save the Bandwidth! ______________________________ Reply Separator _________________________________ Subject: Re: Who Are The Good Guys? Author: Geoff White <geoffw(a)precipice.v-site.net> at Internet-Gateway Date: 5/14/97 3:40 PM On Tue, 13 May 1997, David Stoddard wrote: > > In the war against spam, its getting harder to figure out who > the good guys are. Last weekend, we had an incident where a server > called pure.fiber.net was relaying thousands of spam messages off > one of our mail servers. While we have filters in place to block > the obvious spammers (cyberpromo and others), we don't learn about > new ones until they cross the line (or we get them from Paul's > site at http://www.vix.com/spam -- thanks Paul!). <snip> Indeed things are getting strange, look at this letter I got in my mailbox this morning... -------------------------------------------------------------------------------- -----

1 0

Re: Outage Reports
by Alex Rubenstein 15 May '97

15 May '97

We do some stuff (it generally doesn't include NAP stuff, tho): http://www.nac.net/outages.html some others: http://www.noc.uu.net/ http://www.agis.net/outages.htm At 04:12 PM 5/14/97 -0500, Rizwan Ahmad wrote: >Hi, I have been asked to put together a data base of internet outages and >trouble spots on a daily basis. I was wondering what mail lists, web >pages, and other tools are there out there that will help me with this >task. > >Thanks > > >Rizwan Ahmad >Lead NOC Technician >Nap.Net, L.L.C >(414)747-8747 > >

1 0

Re: UUNET Press Release on Peering
by Ron Buchalski 15 May '97

15 May '97

>From: "William Allen Simpson" <wsimpson(a)greendragon.com> [snip] >As it turns out, the inequality is actually in the other direction. >UUnet is a consumer, not a provider, requesting the traffic from the web >farms. So, it would be the consumers paying the small ISPs, paying >UUnet, paying the web farms. > >UUnet wants it both ways, with them getting paid in the middle.... > Of course, if UUNET (and other BB providers) can't make enough money to keep their network in place and their people motivated (and compensated) properly, they'll have no reason to stay in business, and then the server farms will become regional islands anyway. UUNET would only be interested in paying a farm that they owned! INTERNET - CONTENT = TRANSPORT -rb --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com ---------------------------------------------------------

2 1

PAYMENT INFO
by Pam Ciesla 15 May '97

15 May '97

When paying the NANOG Registration by check please make the check payable to The University of Michigan. Also include the name of the attendee with the check. Thanks Pam xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

prefixes not registered in the IRR/GRR
by Curtis Villamizar 15 May '97

15 May '97

There have been a few recent incidents of incorrect routing information propagated by major providers that have caused substantial outages. An example, though by no means the only example, is the recent AS7007 announcements trig-erred by a routing software bug. In the AS7007 case, some providers had filters in place within 15-20 minutes while others never put filters in place and the upstream provider took over 2 1/2 hours to block the announcements at the source. We've seen similar slow response in other incidents. The AS7007 was easy to detect and isolate because very many destinations where impacted. Other incidents have occurred that impacted a lesser number of prefixes. This type of outage is very hard for a provider to detect. In order to insure that these routing anomalies can no longer impact connectivity within ANS, we will begin filtering routing information based on registered route objects in the IRR/GRR, that is the ANS, CANET, MCI, RIPE, and RADB databases. If you are unfamiliar with the IRR/GRR, documentation is available at: http://www.ra.net/RADB.tools.docs/.docs.html Brief instructions on registering objects are provided at: http://www.ra.net/RADB.tools.docs/register.html During April ANS took routing dumps, analyzed ANS routing policy, and identified 2,829 announced prefixes that were not registered and not covered by an aggregate (reachable anyway). During early April, emphasis was placed on verifying ANS routing policy files. From April 25 to April 29 notifications were sent to 312 origin AS, covering 2,108 of the unregistered prefixes. Notification could not be sent to 151 origin AS covering 721 prefixes due to lack of contact information for the origin AS. Quite a number of the origin AS contacted registered the missing prefixes. Others have not responded and of course those who were not contacted have not corrected problems. We'd like to thank the many people who promptly made corrections. The number of unregistered prefixes has been reduced by almost 1/3. There still remain 2,096 prefixes from 333 origin AS that are not registered. We've put together a web page describing the methodology and listing the remaining unregistered prefixes. The URL is: http://engr.ans.net/route-dumps/ It also interesting to note that 8,562 unregistered prefixes were excluded from these reports because they were overlapped by aggregates. The vast majority of these were /24 prefixes. This may indicate that 8,562 (or more) prefixes need not be included in global routing but are leaking from their aggregates. Curtis

1 0

Who Are The Good Guys?
by David Stoddard 14 May '97

14 May '97

In the war against spam, its getting harder to figure out who the good guys are. Last weekend, we had an incident where a server called pure.fiber.net was relaying thousands of spam messages off one of our mail servers. While we have filters in place to block the obvious spammers (cyberpromo and others), we don't learn about new ones until they cross the line (or we get them from Paul's site at http://www.vix.com/spam -- thanks Paul!). Unfortunately, fiber.net is a 9 to 5, Monday thru Friday operation with no weekend or evening NOC. This made things difficult for us at 2 am on a Saturday night trying to get their attention. Because fiber.net was not known as a spammer, we did not want to unilaterally block them off until we could talk to them when they opened on Monday morning, so we wrote some bash scripts and ran them against our mail queue every three minutes to kill messages with specific attributes relating to the spam. On Monday, we talked with their technical contact and he said that someone on their server must have been misbehaving, but that they would look into it. Today I reviewed my logs and not only did it not stop, but they started ANOTHER spam off our mail servers. When one of our engineers called them this afternoon, they said they were innocent because someone was using them as a relay -- nice try, but if they were a relay, we should not have seen any messages other than those destined for addresses on our network. Instead, we got the entire spam feed. They even went so far as to insert forged Received headers into the messages to try and throw us off. The spammers played us as chumps. Fine -- now I have filters in my backbone routers for 204.250.13/24 and 204.250.192/19, and mail filters for *.fiber.net just in case they manage to get another IP block. Grrrrr. The bottom line is that you cant tell the good guys from the bad guys anymore. There are ISPs that support spammers and then lie about it when they get caught. Even though I detest the fact that AGIS supports cyberpromo, at least they have the guts to tell it the way it is. As an aside, today we got a message in our marketing box asking "Do you support spammers?" -- unbelievable. The poster was looking for an ISP that would allow him to post 500 to 1000 spam messages each day. I sent him a form letter telling him "no" and outlining why spam is a Bad Idea(tm). It is obvious the spammers are getting much more aggresive and may even be compiling lists of spammer friendly ISPs. Its not just getting worse -- its getting weird. Dave Stoddard US Net Incorporated 301-572-5926 dgs(a)us.net

6 7

HOTEL REMINDER
by Pam Ciesla 14 May '97

14 May '97

The Hyatt Regency's cut-off date is May 15 for the NANOG Meeting in Tampa, FL June 5 & 6. Remember to mention the NANOG Meeting when registering. If you have any problems with the 800 number call the hotel direct. If you still have a problem let me know. The phone numbers are 800-233-1234 or (813) 874-1234. Pam xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

3 2

Re: UUNET Press Release on Peering
by William Allen Simpson 14 May '97

14 May '97

> From: smd(a)clock.org (Sean M. Doran) > "William Allen Simpson" <wsimpson(a)greendragon.com> writes: > > In view of the difference, I would suggest that the web farms have a > > case that UUnet should pay _them_ for the priveledge of accessing their > > content! Anytime UUnet asks for a fee for peering, just tell them that > > you really consider them unequal, and that they should > > pay YOU! > > This would be a really good idea because it would give a > strong push into investing in web caching technologies at > the ISP level. Once that's been done, and access-level > devices (customer-aggregating NATs and the like) can be > gotten reliably to intercept queries directed towards > anything other than a web caching hierarchy, in an > intelligent engineering effort to keep traffic as local as > possible when it's possible, the whole spurious argument > that this is about web farms will go away. > Agreed! Welcome back, Sean! > And > wouldn't you start wondering when small providers will > start paying their own customers for the privilege of > talking with them? > You got the shoe on the wrong foot here. If the "inequality" of traffic (cited in the UUnet PR) is the reason for the need for payment by the web farms (cited in the UUnet PR), then it would be the web farms paying UUnet, who then pays the small providers, and the small providers paying their customers. As it turns out, the inequality is actually in the other direction. UUnet is a consumer, not a provider, requesting the traffic from the web farms. So, it would be the consumers paying the small ISPs, paying UUnet, paying the web farms. UUnet wants it both ways, with them getting paid in the middle.... We hashed all these scenarios out on the IETF list a few years ago. As you say, in either direction, it is possible to shift the traffic pattern with caching, and/or other technology. Any settlements proposal skews the market, and would result in a technical push back. I was going to write up "Settlements considered harmful", but never got around to it. Wrote too many other more urgent things, instead.... WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: Warning, CDP interaction at Mae-EAST
by Alex Rubenstein 14 May '97

14 May '97

>no cdp-enable > >Owen Oh, and its: no cdp enable (no dash)

1 0