- NANOG - lists.nanog.org

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

Re: F means filtered ?
by Justin W. Newton 20 Feb '97

20 Feb '97

At 11:35 PM 2/19/97 -0600, Edward Henigin wrote: > > Look, I think y'all are morons. Thank you :) > > 1) if someone floods Paul's network, does that not make the >F root server unusuable to *everyone* ? why doesn't anyone pat him on >the back for taking defensive measures to protect a public resource? >Oh yeah, you know, your public library has locks on the doors, right? >Oh shit, better go take the locks off, the books are public resources, >everyone is supposed to have access! Paul is blocking people who he considers to be spammers from one of the root name servers. He is thus making a decision as to who can and cannot connect to a public resource, which was funded, at least in part, by the internet community (I believe via the DNR infrastructure improvement fund). I repsect Paul immensly, and he has contributed a lot to the community. This does not, however, make it all better that he is deciding who can and cannot connect to the root name server that he runs. This is the last post I am sending on this matter as its only tangentially a NANOG issue I suppose. Justin Newton Network Architect Erol's Internet Services

2 1

FNC Meeting
by Jim Fleming 20 Feb '97

20 Feb '97

No matter which side of the Root Name Server debates you are on, as members of NANOG, it is important that your views are heard by people who make the "real" decisions. Whether you are heard as a group or as individuals your views should be heard. I am sure that people in the U.S. Government and specifically the National Science Foundation will be "doing the right thing" and addressing some of the major issues. Fortunately, there are many checks and balances in the U.S. Government to prevent one person from being the judge, jury, and... There is a Federal Networking Council meeting planned for February 27, 1997. As noted, it is apparently for members only. This should not stop people from "networking" with the people who influence When "networking" is allowed to be redefined as "spam", the entire Internet community is in trouble. This is no different from a sheriff in rural America redefining speeding on a car by car basis, with no judge or jury present and no record of the "fine" that was collected. @@@@ http://www.fnc.gov/calendar.html Feb. 27, 1997 FNC* 1:00-3:00 NSF (* = restricted to members) @@@@@ http://www.fnc.gov/FNC_Members.html Federal Networking Council George Strawn - Chairman GSTRAWN(a)NSF.GOV Walter Wiebe - Executive Director WWIEBE(a)NSF.GOV Bruce Almich ALMICH.BRUCE(a)EPAMAIL.EPA.GOV Bruce Bottomley BBB(a)ROMULUS.NCSC.MIL Dick desJardins DESJARDI(a)EOS.NASA.GOV Frank Hartel HARTEL(a)BOX-H.NIH.GOV Craig Hunt CHUNT(a)NIST.GOV Pamela G. Kruzic PJK(a)NRC.GOV Henry Lai HENRY.LAI(a)GSA.GOV Fred Lee FLEE(a)NSF.GOV Fred Long FLONG(a)SUN1.WWB.NOAA.GOV Hilarie Orman HORMAN(a)DARPA.MIL Camillo J. Pasquariello PASQUARC(a)NCR.DISA.MIL Alexis Poliakoff ALEX_POLIAKOFF(a)ED.GOV Ken Roko KROKO(a)USAID.GOV Elaine Stout ESTOUT(a)USGS.GOV @@@@@ http://www.fnc.gov/FNCAC.html The Federal Networking Council Advisory Committee (FNCAC) is chartered by the National Science Foundation to provide the FNC with technical, tactical, and strategic advice from the constituencies involved in the NREN Program..." FNCAC Members Dr. Sidney Karin KARIN(a)SDSC.EDU Dr. George Brandenburg BRANDENBURG(a)HUHEPL.HARVARD.EDU Dr. Henriette Avram AVRAM(a)IVORY.EDUCOM.EDU Mr. Jim Beall, Jr. BEALL(a)VNET.IBM.COM Mr. Alan Blatecky ALANB(a)MCNC.ORG Mr. Matt Blaze MAB(a)RESEARCH.ATT.COM Ms. Susan Estrada SESTRADA(a)ALDEA.COM Dr. Kenneth S. Flamm FLAMM(a)BROOK.EDU Dr. John Gage JOHN.GAGE(a)ENG.SUN.COM Ms. Carol Henderson CCH(a)ALAWASH.ORG Dr. Kenneth J. Klingenstein KJK(a)SPOT.COLORADO.EDU Mr. Richard Liebhaber 2714743(a)MCIMAIL.COM Mr. Stu Loken SCLOKEN(a)LBL.GOV Dr. Paul Mockapetris PVM(a)SOFTWARE.COM Mr. Robert G. Moskowitz RGM3(a)IS.CHRYSLER.COM Dr. Ike Nassi NASSI(a)SCRUZNET.COM Mr. Carl Edward Oliver OLIVERCE(a)ORNL.GOV Dr. Stewart Personick SDP(a)BELLCORE.COM Mr. Thomas C. Rindfleisch THOMAS_RINDFLEISCH(a)MEDMAIL.STANFORD.EDU. Mr. Mike Roberts ROBERTS(a)EDUCOM.EDU Ms. Connie D. Stout CSTOUT(a)TENET.EDU Brigadier General Harold Thompson THOMPSON(a)ICN.STATE.IA.US Dr. Stephen Wolff SWOLFF(a)CISCO.COM @@@@@ -- Jim Fleming Unir Corporation e-mail: JimFleming(a)unety.net JimFleming(a)unety.s0.g0 (EDNS/IPv8)

1 0

Re: while i'm on the subject of filtering, here's today's list of spammers
by salo＠msc.edu 20 Feb '97

20 Feb '97

> Date: Wed, 19 Feb 1997 15:55:23 -0800 > From: Paul A Vixie <paul(a)vix.com> > [...] > I will not have network resources I pay for, used to spam me, or to spam > others. I have the right of use and/or disposal of my own property. People > who spam are committing "theft of service" and my Ip reachability matrix is > better off without such people in it. > [...] Oh, great. Next, the abortion foes will try to deny the advocates access. Then, the gays versus the straights. The Jews and the Gentiles. ... -tjs

3 3

Re: while i'm on the subject of filtering, here's today's list of spammers
by Brett D. Watson 20 Feb '97

20 Feb '97

> > No, it isn't. You have guests and other users. If you have IP customers, > > then they have guests and other online users. By accepting spam you allow > > your resources (which you offer for cooperative reasons) to be used in a > > noncooperative way. If you have downstream customers you are subjecting > > them to the same abuse. > > We offer our customers Internet access, and when they complain about > spammers we do something about it. However, what we do affects only our > network and our customers. It does not affect the world as a whole? why does everyone keep insinuating that paul is blocking root level name service from the whole world? that's essentially the argument and it's completely off base. i can admit that *maybe* it's not even reasonable (even after my last post) to block *any* entity from reaching a single root name server but this is turning into a tar and feathering of paul for "affecting the world as a whole" which is way out of proportion. > > connections. > > Again, you can't block everyone. Why you feel it necessary to impose your > social mores on the net as a whole is beyond me. sigh. when has he imposed his social mores on anyone here? paul blackholes spam sites *within* his own network which he pays for. he happens to run a public root name server (one of many) and the spam sites are denied access to part of the public resource (root name service). you can *actively* (as opposed to passively or without your permission) take this list of networks from paul via a bgp peering session and block access from spammers within your own network. so where in that scenario is paul forcing morals on anyone? or blocking the "whole world" from reaching a root name server in his network? -brett

1 0

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

20 Feb '97

> > I operate a cooperative resource. I will not have it used against me. > > This is not negotiable. I pay for my part of the Internet and anyone > > who wants their traffic to traverse it has to make sure that I derive > > similar value, in the aggregate, to theirs when they send me traffic. > > No argument -- as long as a public root server isn't there. If it wasn't > I'd be SUPPORTING your black-hole list. But it is, and as such I'm not. for the record, i believe in what paul is doing as i am one of the people taking the black-hole feed from him. that said, this seems to be the primary arguement that people are using against paul black-holing spammers. it makes no sense to me. you are saying paul is blocking access to a public service ( a single root name server) but *you* and 99.9% of the rest of the internet are not being blocked. on the other hand, people that are *stealing* (and yes, i agree with paul that it's theft) resources from his network are being blocked. that is, their access to *one* of 15, or whatever the number is now, public root nameservers is blocked. i would understand this argument if the server paul ran were the *only* publicly available root name server on the internet but there are many more. so it's likely that name service for the spammer is not affected in *any* way due to redundancy. and the rest of you merrily go on resolving "." queries with no trouble. so i guess you are advocating that it's ok if a spammer decides to mail bomb paul, clogging up his network with bogus mail, and slowing down access to a root name server, possibly denying valid queries to that root name server at all? that's ok with you, but blocking the very small percentage of thieves from accessing one root nameserver is a bad thing. > > same protection I work so hard to give myself, and I am donating that > > protection to anyone who wants it. > > The point is, you can do that, hurt the spammers even more, and still find > ways to distribute the file (it IS only a flat file Paul) on an automated > basis, rapidly, if you want. > > AND, you don't cut off a non-related resource (a root nameserver) in the > process. the *resource* (root name service) is *not* being cut off. even to the spammer. one server i that provides redundancy *for* the resource happens to be. something i'd think most are willing to live with to stop theft of resources on their networks and to/from their customers. i certainly am. -brett

1 0