February 1997 - Test - lists.nanog.org

Re: BGP4 tutorial slides
by sthaug＠nethelp.no 21 Feb '97

21 Feb '97

> The BGP Tutorial Slides are now on line at this URL: > http://www.academ.com/nanog/feb1997/BGPTutorial/index.htm I see Paul's last name has become "Furguson" on that page :-) Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Re: BGP4 tutorial slides
by sob＠academ.com 20 Feb '97

20 Feb '97

The BGP Tutorial Slides are now on line at this URL: http://www.academ.com/nanog/feb1997/BGPTutorial/index.htm Enjoy. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

ISPCON 97 - Aug 20-23rd - San Francisco (fwd)
by Michael Dillon 20 Feb '97

20 Feb '97

SUMMARY: ISPCON 97 - August 20-23rd, 1997, San Francisco Hilton, More at http://www.ispcon.com. I snipped the following "Call for papers" bit out of Jack's announcement on another list. ---------- Forwarded message ---------- Date: Thu, 20 Feb 1997 14:33:24 -0700 From: Jack Rickard <jack.rickard(a)boardwatch.com> We're also issuing a call for papers for those who would like to present in the educational session schedule. As many of you know, we did over 120 sessions last year with very little in the way of the feel-good pap you may be accustomed to at most of these trade show events. We don't do "Internet is Cool" stuff. But if you have a concept for a solid technical session, or something productive on legal, business, or economic issues facing ISP's, we're all ears now and it gets very difficult to work in during the last week of July when it will probably finally occur to you. Papers should include a summary of the session, a bio paragraph on the speaker, full speaker contact information, and if possible a photo suitable for publication. Address session proposals to ISPCON Session Schedule, Boardwatch Magazine, 8500 West Bowles Ave., Suite 210, Littleton, CO 80123. Jack Rickard Boardwatch Magazine

1 0

Cyber Promotions
by Christian Nielsen 20 Feb '97

20 Feb '97

We are looking at setting up the filters on our routers from Paul. The reason, yea, we can watch for junk mail coming in, but we might be 10 min too late. And as we saw come across the wire today...... Associated Press PHILADELPHIA It's about to get much easier for advertisers to send junk e-mail on the Internet.Cyber Promotions Inc. will launch the first bulk e-mail friendly Internet provider in the nation on March 17. It will allow computer users to send millions of commercial ads also known as spam for a single monthly fee. http://www.desnews.com/newbiz/ia0lb0tx.htm Christian

6 7

Re: karl and paul, expostulating
by Daniel Simms 20 Feb '97

20 Feb '97

>>>>> "KD" == Karl Denninger <karl(a)Mcs.Net> writes: KD> or a 421 error, which keeps the spam at the source (loading the KD> spammers mailserver -- a GOOD thing!) Are you joking? There's not a spammer alive that uses sendmail or something that would similiarly requeue on temporary failure. KD> Much more elegant, in my opinion. Assuming that 'sendspam' would actually maintain a queue. Paul's solution has its own elegance: raising the price for allowing antisocial behavior from bounced email to partial loss of connectivity. But like Paul said, raising the stakes like that just invites someone to try and one up him. -- Daniel Simms There is more than one way to burn a book. dsimms(a)alink.net And the world is full of people running (408) 720-6161 about with lit matches. -Ray Bradbury

5 7

Re: karl and paul, expostulating
by Brett D. Watson 20 Feb '97

20 Feb '97

> >Filtering packets based on source address makes Ciscos go way slow on > >every packet. Filtering based on destination address makes Ciscos go > >very fast on most packets and a little slower on SYN-ACKs. > > If you enable flow switching it adds little overhead to the box. doesn't matter. in production ios, policy routing (source based routing) is process switched. there is code in the works to make it fast switched. but there is a bug wherein if you do policy routing, and you enable flow or optimum switching on the interface you're doing pr on , it disables the policy routing. that bug may be fixed now but in any case enabling flow switching will *not* speed up policy routing. and if you're exporting the flow stats, you lose anywhere from 50kpps to 100Kpps of speed. > On a 7505 > with 2 sets of full routes and another partial set of routes (and all of > the updates associated), that pushes some pretty significant traffic, I am > filtering approx 25M/sec of data with 25k long extended access list. The > total CPU load on the box is approximately 35%. Oh yeah, the box is also > the DR for area 0 of a fairly large OSPF network (approximately 3k routes). > Before flow switching was enabled we were running at 80% or so (not for > more than a few minutes before we enabled flow switching though). but i'm assuming you aren't doing policy routing in this box nor exporting flow stats? -brett

2 1

Re: karl and paul, expostulating
by Justin W. Newton 20 Feb '97

20 Feb '97

At 07:23 PM 2/19/97 -0800, Paul A Vixie wrote: Wahoo, a nanog issue :) >> Filtering by connection to the SMTP port, based on source address, very >> definitely DOES work. > >Filtering packets based on source address makes Ciscos go way slow on >every packet. Filtering based on destination address makes Ciscos go >very fast on most packets and a little slower on SYN-ACKs. If you enable flow switching it adds little overhead to the box. On a 7505 with 2 sets of full routes and another partial set of routes (and all of the updates associated), that pushes some pretty significant traffic, I am filtering approx 25M/sec of data with 25k long extended access list. The total CPU load on the box is approximately 35%. Oh yeah, the box is also the DR for area 0 of a fairly large OSPF network (approximately 3k routes). Before flow switching was enabled we were running at 80% or so (not for more than a few minutes before we enabled flow switching though). >Sez you. I'd ordinarily expect you to love the idea of "if you don't play >by my rules I will start my own Internet without you on it." Go ahead and do so, but not with public resources. >And, again, wrong. I want spammers to spend 75 seconds of TCP PCB time on me. >By blackholing SYN-ACKs and not sending them ICMPs, they lose capacity that >they could otherwise spend spamming other people. I call this "fighting >dirty." Is having them time out on DNS requests so that their entire system runs slower fighting dirty as well? >I operate a cooperative resource. I will not have it used against me. What kind of a port adapter do you need so as not to have to filter the traffic to the root name server? Justin Newton Network Architect Erol's Internet Services

2 1

Re: BOF minutes from NANOG meeting
by sob＠academ.com 20 Feb '97

20 Feb '97

Acknowledged! -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: karl and paul, expostulating
by Brett D. Watson 20 Feb '97

20 Feb '97

> > What's so elegant about that if a spammer with elementary knowledge > > about SMTP and DNS can easily bounce his stuff off of any of the > > thousands of unsuspecting hosts and/or use unsuspecting forwarding > > name servers in the slave mode? > [ ... ... ] > > They rotate phaser frequencies, we rotate shield frequencies. And while > the war of escalation goes on, providers are educated -- and that's the > real goal, so no matter who's "winning" at the moment, *I* am winning. make that "we". -brett

2 1

while i'm on the subject of filtering, here's today's list of spammers
by Paul A Vixie 20 Feb '97

20 Feb '97

if you're listed and think you shouldn't be, give me a call (you can't send me mail). and yes, these same thieves are also prevented from reaching the F.ROOT-SERVERS.NET host, but lack of reachability to one NS doesn't break their service. why in the world are we discussing this on NANOG? # general spam 204.141.123 masklen 24 interface lo0 reject; # Cybernex 208.1.117 masklen 24 interface lo0 reject; # Intgrtd Med. Promtns 208.8.32 masklen 24 interface lo0 reject; # Idea Concepts 207.76.82 masklen 24 interface lo0 reject; # hardchannel 206.222.107.192 masklen 29 interface lo0 reject; # telysis 207.86.199 masklen 24 interface lo0 reject; # onlinebiz / covesoft 207.217.56.116 masklen 32 interface lo0 reject; # mailloop.com 38.220.191 masklen 24 interface lo0 reject; # quantumcom 205.136.220.60 masklen 32 interface lo0 reject; # shadowgrp (IDCI) 204.183.199.231 masklen 32 interface lo0 reject; # xshadowx (uServe?) # softcell spam 199.250.187.72 masklen 32 interface lo0 reject; # www CNAME/A # cyberpromo spam 207.120.161.73 masklen 32 interface lo0 reject; # www.cpmall.com 207.124.161 masklen 24 interface lo0 reject; # NS8, NS9 (IDCI) 205.199.212 masklen 24 interface lo0 reject; # NS5 (AGIS) 208.5.0.0 masklen 20 interface lo0 reject; # NS10 (Crawford) 206.27.86.210 masklen 32 interface lo0 reject; # NS7 (ACUN)

8 14