- Test - lists.nanog.org

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

Updated Speaker List for the 9th Maryland Workshop on Very High Speed Networks VHSN 1998
by Account of Maryland Center for Telecommunications Research 03 Dec '98

03 Dec '98

*************************************************************************************** List of Speakers 9th Maryland Workshop on Very High Speed Networks (VHSN'98) December 14 - 15, 1998 Maryland Center for Telecommunications Research University of Maryland Baltimore County *************************************************************************************** Supported By Cisco Systems,CESDIS/NASA, Fore Systems, Nortel Networks, Corvis, MCI Worldcom *************************************************************************************** David Tannenhouse, DARPA (title to be conformed) Henry Dardy, NRL ATDnet: Moving from ATM to Transparency D. Raychaudhuri, NEC Broadband Wireless Networks: Technology Status and Future Prospects Pat Dowd, NSA Security in Broadband Networks Pat Gary, NASA High End Computer Networking at Goddard Space Flight Center Doug Montgomery, NIST NIST Efforts in Next Generation Internet Technology Scott Ferguson, Nortel Networks Secure Virtual Private Networks: Technology and Applications Yuet Lee, Nortel Networks Gigabit Ethernet: Current Developments and Future Directions/Trends Allwyn Sequeria, Nortel Networks Multimedia over ATM Tim Thomas, CISCO Tag Switching & MPLS Randy Wood, CISCO Multimedia over IP (....), CISCO Gigabit Ethernet Pete Chadwick, Avici Systems Building the 21st Century Network Daniel O. Awduche, UUNet Technologies MPLS and Traffic Engineering in IP Networks Michael O'Dell, UUNet Technologies Pretty good challenges in building large networks Helen Chen, Sandia National Labs Jumbo Frame for Gigabit Ethernet and Protocol for a "Wire in Space" Brad Mackrucki, Rendall and Associates Broadband wireless access and capacity analysis Anthony Rutkowski, NGI Associates Framework and Overview for Next Generation Internet Developments (...) and Allison Mankin, ISI (title to be confirmed) Roch Guerin, UPen QoS Routing in IP Networks: Experiments and Initial Findings Pravin Bhagwat, IBM Watson Research Center TCP Splicing for Application Layer Proxy Performance (....), IBM Watson Research Center *** Electronic Commerce Technologies *** (....), Fore Systems (title to be confirmed) Alden Jackson, BBN Technologies Smart Spaces Hemant Kanakia, Torrent Networking Technologies High Performance Routing S. Finkler, C. Sweet and D. Sidhu, MCTR/UMBC Gigabit Ethernet and Wireless LAN Standards: Detailed Performance Analysis *************************************************************** 9th Maryland Workshop on Very High Speed Networks December 14-15, 1998 *************************************************************** Maryland Center for Telecommunications Research University of Maryland Baltimore County Supported by CISCO, Nortel Networks, Corvis Fore Systems, CESDIS/NASA and MCI Worldcom The Maryland Center for Telecommunications Research (MCTR) at the University of Maryland Baltimore County (UMBC) will hold the 9th Maryland Workshop on Very High Speed Networks (VHSN '98) on December 14-15, 1998. The Workshop will be held in the Ballroom of the University Center on the UMBC campus. The goal of the workshop is to provide a forum where researchers and developers can meet to exchange ideas and report on leading- edge developments in the area of high speed networks. Each of the previous workshops attracted approximately 150 researchers representing academia, industry and government. The two day meeting will include invited speakers and contributed presentations. Papers on selected presentations will appear in a special issue of the Journal of High Speed Networks. The agenda, driving directions, and other information regarding the conference can be found at the URL http://www.mctr.umbc.edu. A registration fee of $350 will include two lunches and conference proceeding. For questions regarding the technical content of the workshop or giving a presentation, please contact the workshop organizer: Dr. Deepinder Sidhu, Tel: (410) 455-3028 or 3063, Fax: (410) 455-3969, Email: mctr(a)cs.umbc.edu. Mail checks (payable to University of Maryland Foundation) and registration form to Dr. D. Sidhu, Maryland Center for Telecommunications Research, University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore, MD 21250. All funds for this event will be managed by the UM foundation. Please DO NOT include hotel accommodation expenses in your payment for the Workshop Registration. Room payment should be made directly to the hotel you selected for stay. The following hotels are closest to UMBC campus. Some hotels may offer reduced rate. To obtain the reduced rate, you must identify yourself as an attendee of this workshop. BWI Airport is approximately five miles from UMBC Campus. * Sheraton International Hotel - BWI Airport. Closest to airport and UMBC campus. Tel: (410) 859-3300 or (800) 638-5858 * Holiday Inn - BWI Airport. Close to airport and UMBC campus. Tel: (410) 859-8400 or (800) HOLIDAY * Omni Inner Harbor Hotel. Close to Downtown Baltimore/Inner Harbor. About 20 minutes drive to UMBC campus. Tel: (410) 752-1100 or (800) 843-6664 For more information on the workshop and directions to UMBC, check our home page on WWW (http://www.mctr.umbc.edu) --------------------------------------------------------------- VHSN '98 REGISTRATION FORM (December 14-15, 1998) Name: Affiliation: Address: Tel: Fax: Email: Dietary Restrictions: Vegetarian ------ Kosher -------- --------------------------------------------------------------- ------------------------------------------------------------------------- Maryland Center for Telecommunications Research (MCTR) Room: 227 ECS Department of Computer Science & Electrical Engineering Tel:410-455-3063 1000 Hilltop Circle, Fax:410-455-3969 University of Maryland Baltimore County (UMBC) Email: mctr(a)cs.umbc.edu Baltimore MD 21250 http://www.mctr.umbc.edu -------------------------------------------------------------------------

1 0

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

03 Dec '98

Howdy, When our network is being smurfed, we can call our ISPs and have them setup an access list to block ICMP. That fixes the problem, but it creates another (obvious) problem. Could traffic shaping, or similar QoS configurations, be used to solve such issues in a more general way? For example, if my source of packet flooding is ICMP, then I'd like to be able to dedicate as much as 1/10th (e.g.) of the bandwidth of each link to ICMP. That's plenty of ICMP, but it's not so much that an attack using ICMP would be effective. My question, stated briefly, is this: can you solve generic homogenous-packet-flood problems with QoS and/or traffic shaping (if the two can be truly distinguished), in general? If so, are current routers capable of doing it? What would be the effect of doing so on dialup links and backbones? --- Mark R. Lindsey, mark(a)datasys.net Internet Engineering, DSS Online LLC Voice: 912.241.0607x200, Fax: 912.241.0190 (US)

5 4

Operational issue: MAE-WEST
by dlr＠daver.bungi.com 03 Dec '98

03 Dec '98

Looks like AC power was lost at the MFS-side mae-west, around 00:30. No generator, yet. Dave Rand

1 0

Re: identify hostname
by Brandon Ross 03 Dec '98

03 Dec '98

On Mon, 30 Nov 1998, Dan Hollis wrote: > On Mon, 30 Nov 1998, Brandon Ross wrote: > > 1Cust76.tnt1.sfo2.da. > > Id say that looks like uunet. Again. Sigh. > > UUnet uses ascend TNT's which they claim you cant filter > directed-broadcast on. Ive ranted at them since October 20 to get this > serious security hole closed. I've been yelling at them about that as well as not being able or willing to reverse trace spoof attacks. This attack, however, would not have been stopped by such filters, this is just the address that someone used to break into a server with. Thanks for your help. 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.

5 4