December 1998 - NANOG - lists.nanog.org

Re: Lawsuit threat against RBL users
by Dean Anderson 05 Dec '98

05 Dec '98

At 11:53 PM 12/3/1998 -0500, Scott Lampert wrote: > I don't know about where you live but here in BellSouth land you can >call the phone company and block outgoing 900 number calls from your line. Correct: YOU can ask to have things blocked on YOUR line. The phone company (or ISP) can't do that without YOUR permission. But if (say a CLEC) offers phone services without any 900 services, they have your permission when you sign up. Likewise, YOU can use the RBL to block YOUR mail, and your ISP can use the RBL if you give them permission. Which you do for example (according to US Attorney somewhere), if their service definition includes blocking. The ethics of the RBL and its ability to coerce people and organizations arbitrarily notwithstanding, its existance is probably not illegal. However, that does not mean that it can't be used to illegally block mail by people that don't have permission to block. The idea promulgated by some that a network operator can do whatever they feel like with "their equipment" is plainly wrong. There are laws which govern how that equipment can be used by its owners. The people who feel otherwise seem to be falling into the kook category, so I don't see any point in arguing further. 'Szechuan Death' brings up some good ethical and moral points about the RBL. ORBS is even more arbitrary and unethical. But I'm not sure this is of any operational importance. Hasn't the operational value of this discussion been exhausted? --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Worldcom Fiber Cut - Orlando, FL
by Mark Moore 04 Dec '98

04 Dec '98

Worldcom has reported a fiber cut between Lake Mary and Orlando, FL. No word yet on repair time or how many circuits are down. ~mark ---------------------------- Mark Moore <mark(a)gleim.com> Network Administrator Gleim Publications, Inc. http://www.gleim.com (352) 375-0772 ext. 116 (800) 87-GLEIM ext. 116 FAX: (352) 375-6940 -----------------------------

1 0

The Cidr Report
by Tony Bates 04 Dec '98

04 Dec '98

This is an auto-generated mail on Fri Dec 4 12:00:00 PST 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 04Dec98 0) General Status Table History ------------- Date Prefixes 271198 54161 281198 53936 291198 53897 301198 54139 011298 54213 021298 54287 031298 54269 041298 56909 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4292 Number of ASes announcing only one prefix: 2100 (1123 cidr, 977 classful) Largest number of cidr routes: 353 announced by AS3561 Largest number of classful routes: 981 announced by AS701 1) Gains by aggregating at the origin AS level --- 04Dec98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 349 152 197 56.4% BCnet Backbone AS3749 230 70 160 69.6% TECNET AS2493 335 188 147 43.9% iSTAR Internet, Inc. AS1785 534 400 134 25.1% NYSERNet Backbone AS701 981 848 133 13.6% Alternet AS174 688 557 131 19.0% Performance Systems International AS5668 125 39 86 68.8% Century Telephone Inc. AS4200 170 90 80 47.1% AGIS (Apex Global Information Ser AS1267 109 30 79 72.5% IUNET-AS AS4755 135 63 72 53.3% Videsh Sanchar Nigam Ltd. India AS4293 205 133 72 35.1% IMCI AS549 223 155 68 30.5% ONet Backbone AS4740 388 328 60 15.5% Ozemail Pty Ltd (ASN-OZEMAIL) AS1221 387 330 57 14.7% AARNET-AS AS8517 127 71 56 44.1% UNKNOWN AS7046 258 202 56 21.7% UUNET-CUSTOMER AS6335 71 19 52 73.2% NTRNET AS7545 117 66 51 43.6% TPG Internet Pty Ltd AS72 88 40 48 54.5% Schlumberger Information Network AS7657 134 87 47 35.1% The Internet Group Limited AS1239 524 477 47 9.0% SprintLink Backbone AS577 210 165 45 21.4% CA*net Networking Inc Backbone AS7496 75 31 44 58.7% Power Up AS3221 84 42 42 50.0% RIPE-ASNBLOCK4 AS852 170 129 41 24.1% AGT Advance Communication AS10928 89 48 41 46.1% UNKNOWN AS719 440 401 39 8.9% LANLINK-AS AS7122 113 76 37 32.7% MTS ADVANCED Network Policy AS803 71 35 36 50.7% SaskNet Backbone AS3564 69 36 33 47.8% Microserve Infromation Systems In For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: Effects of traffic shaping ICMP (&c.)
by Hank Nussbacher 04 Dec '98

04 Dec '98

At 09:43 PM 12/3/98 -0500, Mark R. Lindsey wrote: >: ==>Could traffic shaping, or similar QoS configurations, be used to solve >: ==>such issues in a more general way? >: >[...] >: It has information on using Cisco's Committed Access Rate (CAR) feature >: to rate-limit traffic such as ICMP echo/echo-reply and TCP SYNs. > >Thanks, everyone, for your responses. It seems that lots of us agree >that CAR sounds like a wonderful mechanism for taming smurf-like >attacks. (Thanks, Cisco and others who have provided it.) > >So isn't this the solution(**) to smurfing that we should be lobbying for? >Consider: Using CAR to limit ICMP to a statistically normal range on >all links has these features: > * It can be implemented from the core out > * It must be implemented by clueful network operators (because they > run the core) > * It must be implemented on a relatively small handful of > rigorously-maintained routers Implementing it on the core has some limitations. CAR works on a per protocol basis - not on a per flow basis. This means that someone with an OC-3 to some NAP might want to limit ICMP to 500kb/sec or some other reasonable number. What you want is not only an upper limit but a 8kb/sec limit on per flow or some other reasonable number. You also want a guarantee on certain IP addresses to get through and not be limited by CAR. When the Smurf is happening, you don't want your NOC pings and traceroutes dropped because of some CAR limit being exceeded. So you need to create a careful policy as to what gets bypassed by CAR limits and what gets shaped by CAR limits. -Hank > >Compare this to the drive for limitations on directed broadcasts: > * It must be implemented at the edges > * It must be implemented by widely-varying clue levels > * It must be implemented on hundreds of thousands of routers that no > one ever touches > >In short, the core grows slower, and is run by people with more experience. >If the problem can be addressed there, then it seems like we *must* address >it there. > >Comments, please. > > > >(**) You could well argue that limiting ICMP traffic on core/distribution > links doesn't actually solve the problem -- lots of trash traffic > can be generated on networks whose routers allow directed broadcasts. > But that's if we define the problem to be trash ICMP because > hosts reply to pings (or fraggle, or whatever); in such a case, > traffic limitations are simply a kludge. > > However, if you define the problem to be packet floods, then I think > CAR provides a viable and real solution. After all, directed broadcast > is a useful tool; in such a definition, disabling it on a network > is a kludge. My limited studies seem to show that there are enough > smurf amplifiers on the Internet to easily saturate OC-48s. Perhaps > the real problem *is* flooding -- not directed broadcast. > >

1 0

RE: Lawsuit threat against RBL users
by Chris Mauritz 04 Dec '98

04 Dec '98

That's a pretty shortsighted view, Sheryl. I suspect you haven't been on the receiving end of some idtiot buying a leased line/virtual web presence from you and then spamming from an AOL/PSI/earhlink/yadda yadda account. It isn't pleasant. Folks aren't stupid. They ignore the fact that the tool used to spam was a throwaway account and go right for the jugular (you). It's better to have a zero tolerance policy and not have to deal with the silliness in the first place. Chris Chris Mauritz Director, Systems Administration Rare Medium, Inc. chrism(a)raremedium.com -----Original Message----- From: Sheryl Chapin [mailto:schapin@ctel.net] Sent: Thursday, November 19, 1998 8:48 AM To: nanog(a)merit.edu Subject: Re: Lawsuit threat against RBL users >That's right. It stops the practice of using a sacrificial account, from >AOL or netcom, to spam for a web-site that is otherwise protected. Does it >make a difference that they didn't spam from their own ISP? That customer >is *still* a spammer whether they did it from your site or not. Maybe >you're of the "It's alright as long as they don't do it here" crowd? Well, >that's one of the things that the RBL was built for. The rest of us don't >have to put up with your negligence. I don't see it as "it's alright as long as they don't do it here". I see it as "I have control over my network, but not over anyone elses". I have an AUP that specifically states spamming is not allowed. I have kicked off users who have spammed. However, I do not have an AUP that says "If you ever spam anyone ever in the world on any network anywhere I will disconnect whatever service you have". I don't control the entire internet, just my little piece of it. :-) Sheryl Chapin Senior Network Engineer CommTel Internet 207.377.3508 Winthrop, Maine schapin(a)ctel.net

19 23

197/8
by Andrew Partan 04 Dec '98

04 Dec '98

Question: is 197/8 being allocated? I see these: MAE-East Looking Glass Results ----------------------------------------------------------------- Query: bgp Addr: 197.0.0.0 255.0.0.0 l BGP table version is 13188566, local router ID is 165.117.1.121 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i197.67.126.0 198.32.136.129 4294967294 100 0 1239 i * i197.71.190.0 137.39.129.153 4294967294 100 0 701 816 i * i197.98.2.0 198.32.136.129 4294967294 100 0 1239 i ----------------------------------------------------------------- But I also see this: asp@home-9189: whois -h whois.arin.net 197.0.0.0 IANA (NETBLK-RESERVED-13) Information Sciences Institute University of Southern California 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 Netname: RESERVED-13 Netblock: 197.0.0.0 - 197.255.255.255 Thanks, --asp(a)partan.com (Andrew Partan)

3 3

Re: Effects of traffic shaping ICMP (&c.)
by mark＠vielle.datasys.net 04 Dec '98

04 Dec '98

: ==>Could traffic shaping, or similar QoS configurations, be used to solve : ==>such issues in a more general way? : [...] : It has information on using Cisco's Committed Access Rate (CAR) feature : to rate-limit traffic such as ICMP echo/echo-reply and TCP SYNs. Thanks, everyone, for your responses. It seems that lots of us agree that CAR sounds like a wonderful mechanism for taming smurf-like attacks. (Thanks, Cisco and others who have provided it.) So isn't this the solution(**) to smurfing that we should be lobbying for? Consider: Using CAR to limit ICMP to a statistically normal range on all links has these features: * It can be implemented from the core out * It must be implemented by clueful network operators (because they run the core) * It must be implemented on a relatively small handful of rigorously-maintained routers Compare this to the drive for limitations on directed broadcasts: * It must be implemented at the edges * It must be implemented by widely-varying clue levels * It must be implemented on hundreds of thousands of routers that no one ever touches In short, the core grows slower, and is run by people with more experience. If the problem can be addressed there, then it seems like we *must* address it there. Comments, please. (**) You could well argue that limiting ICMP traffic on core/distribution links doesn't actually solve the problem -- lots of trash traffic can be generated on networks whose routers allow directed broadcasts. But that's if we define the problem to be trash ICMP because hosts reply to pings (or fraggle, or whatever); in such a case, traffic limitations are simply a kludge. However, if you define the problem to be packet floods, then I think CAR provides a viable and real solution. After all, directed broadcast is a useful tool; in such a definition, disabling it on a network is a kludge. My limited studies seem to show that there are enough smurf amplifiers on the Internet to easily saturate OC-48s. Perhaps the real problem *is* flooding -- not directed broadcast.

1 0

Re: identify hostname
by Jonathan Mischo 04 Dec '98

04 Dec '98

To add to this, it's very simple to identify smurf amplifiers. All you need to do is sequentially ping possible broadcast addresses within a netblock. If you wrote a threaded application, you could probably have a complete list in a day or two on a modem connection. If you think of how many of these fools have a colo box on someone's network, you'd realize that it would be fairly easy to compile such a list once a month, without anyone noticing the traffic (assume 16 hosts/sec, 3 pings per second @ 56 bytes, plus 8 bytes or ICMP header = 3072 bytes/sec)...there are very few providers who are set up to track ICMP traffic density, and 3k of traffic per second is not going to create a noticable bump on a 45-155 meg interface. The occasional amplifier that is hit will only create increased traffic for the 3 pings recieved, which would easily be logged, but would be too short to even produce a spike on most traffic graphs, or trigger a traffic alarm. just my $.02. -Taz -- Jonathan "Taz" Mischo -- Network Slave -- supertaz(a)mindspring.net Mindspring Enterprises, Inc. 1430 W. Peachtree St. Suite 400 Atlanta, GA 30309 1.800.719.4664 x2705 404.287.0770 x2705 fax: 404.287.0885 pager: pagetaz(a)netops.mindspring.net M-F2-10pET On Thu, 3 Dec 1998, Brandon Ross wrote: > On Wed, 2 Dec 1998, Phil Howard wrote: > > > AFAIK, today, smurfers are only using *.*.*.255. They would have to > > track a lot more information to use others, so for now I can generally > > expect that deny to prevent us from being an amplifier. > > I'm afraid that in my experience, that's not true at all. I've seen smurf > attacks bounced off of networks as small as /30's and all the way up to > one network that was a /22, as well as everything inbetween, and I'm not > just talking about the last /30 in a /24 either. > > Brandon Ross Network Engineering 404-815-0770 800-719-4664 > Director, Network Engineering, MindSpring Ent., Inc. info(a)mindspring.com > ICQ: 2269442 > > Stop Smurf attacks! Configure your router interfaces to block directed > broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details. >

1 0

Re: identify hostname
by Roeland M.J. Meyer 04 Dec '98

04 Dec '98

That won't work for them because you are using the same data to build filters. In fact, you can do it in a script, automate the whole thing.. At 06:29 PM 12/3/98 -0500, Jonathan Mischo wrote: >this makes sense...until someone gets lazy, and takes a week to filter, >and the smurf brats catch on, and start querying DNS to find amplifiers. > >-Taz > >-- >Jonathan "Taz" Mischo -- Network Slave -- supertaz(a)mindspring.net >Mindspring Enterprises, Inc. 1430 W. Peachtree St. Suite 400 >Atlanta, GA 30309 1.800.719.4664 x2705 404.287.0770 x2705 >fax: 404.287.0885 pager: pagetaz(a)netops.mindspring.net M-F2-10pET > >On Thu, 3 Dec 1998, Roeland M.J. Meyer wrote: > >> At 11:32 AM 12/2/98 -0700, Pete Kruckenberg wrote: >> >> I do have an access list deny for incoming destinations to *.*.*.255 >> >> since I do know that the only customer we have with larger than a /24 >> >> from us (via cw.net) also happens to have nothing larger than /26 in >> >> their network. AFAIK, today, smurfers are only using *.*.*.255. They >> >> would have to track a lot more information to use others, so for now I >> >> can generally expect that deny to prevent us from being an amplifier. >> > >> >It's not difficult to find subnet broadcast addresses, since few routers >> >(if they even support it) are configured to filter ICMP replies. If there >> >isn't already software out there, it will take all of a few hours to add >> >broadcast-finding code to the smurfing software in existence. >> >> Guys, >> >> Why not make your down-stream fill out a *complete* IN-ADDR.ARPA file which >> lists their sub-net bcast and base addresses? That way yo could use the DNS >> system itself to find those addresses. >> ___________________________________________________ >> Roeland M.J. Meyer, ISOC (InterNIC RM993) >> e-mail: <mailto:rmeyer@mhsc.com>rmeyer(a)mhsc.com >> Internet phone: hawk.mhsc.com >> Personal web pages: staff<http://www.mhsc.com/~rmeyer>.mhsc.com/~rmeyer >> Company web-site: <http://www.mhsc.com/>www.mhsc.com >> ___________________________________________________ >> Who is John Galt? >> "Atlas Shrugged" - Ayn Rand >> > ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer(a)mhsc.com Internet phone: hawk.mhsc.com Personal web pages: staff<http://www.mhsc.com/~rmeyer>.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com ___________________________________________________ Who is John Galt? "Atlas Shrugged" - Ayn Rand

2 1

Re: identify hostname
by Dean Anderson 03 Dec '98

03 Dec '98

You don't need a tool. People already have provisioning/configuration tools or are doing it by hand. Whichever is the case, just add a rule to your customers interface. You know when you configure the interface what the mask is and what the broadcast is. All you need to do is add an access list entry which applies to that customers interface. The only real problem with this approach is customers which have large blocks. If you have a /16, you are almost certainly not using x.y.255.255 as a broadcast. It is hard to know or predict what their subnet strategy might be, but for such customers, you probably don't really need to worry, and can expect a higher clue level from them. They can put their own filters in place. --Dean At 03:41 PM 12/1/1998 -0500, Jon Zeeff wrote: > >Who is willing to write a tool to do broadcast address discovery and >access-list generation? Ideally with a config file that would allow >one to avoid serious self smurfing (ie, ranges to check and patterns >to assume are broadcasts without trying them). > >> Filtering broadcast addresses is pretty ugly. Consider that a single Class >> C broken down into /30's can have 64 broadcast addresses. Maybe if it was >> just filtering your own assigned subnets, it would be possible, but this >> also applies to customer-subnetted broadcast addresses, so you'd have to >> coordinate your filter with every one of your customers, every time they >> change subnets. Not impossible, but pretty close. > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

10 11