- NANOG - lists.nanog.org

Re: Smurfing
by William Allen Simpson 14 Feb '98

14 Feb '98

Wow, I was glad to see that all these wonderful folks are reading the router requirements (RFC-1812, June 1995). Good, good. What I'd like to understand is how smurf attacks can work, even with directed broadcast on? Isn't there a requirement (RFC-1122) from ages past (October 1989) that ICMP not respond to broadcast or multicast [page 38 et seq]? What pressure is being put on host vendors? Which host vendors are the problem? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

2 2

Re: Smurfing
by Steve Hultquist 13 Feb '98

13 Feb '98

Don't these answers answer a different question? Isn't the question how to filter *outbound* attacks, not inbound ones? Filtering the inbound ones is pretty easy on a Bay or anything with filters (drop packets bound for the broadcast addresses). Filtering outbound is another story, especially with CIDR. I would like to set up my routers to make sure I'm protecting as much of the 'net as possible from attempts by my customers to do evil. However, it's not clear to me how to do that. Does "no ip directed-broadcast" somehow filter the *outbound* attacks or just the inbound ones? -- Steve Hultquist, Chief Technology Officer HSAnet providing high-speed Internet access Boulder, Colorado mailto:ssh@HSAnet.net +1.303.581.0800 http://www.HSAnet.net/

4 3

Re: Smurfing
by Chris A. Icide 13 Feb '98

13 Feb '98

At 02:52 PM 2/13/98 PST, Randy Bush wrote: > >why should this not have become the default mode for all vendor diustributed >router code? > was that meant to be "distrusted" code, or distributed? :) either way, we may want to do a quick list of such commands, including the following: ip classless ip subnet-zero what ones did I miss? ************************************************************** Chris A. Icide voice: +1-650-482-2840 Chief Technology Officer fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "Tommorrow's Performance Today." - Notice: NVRAM invalid, possibly due to write erase. Press RETURN to get started! - PGP Keys located at pgpkeys.mit.edu **************************************************************

1 0

Re: Multicast and Digex?
by Steve Hultquist 13 Feb '98

13 Feb '98

--On Thursday, February 12, 1998, 1:28 PM -0500 "Eric Germann" <ekgermann(a)cctec.com> wrote: > Anyone from Digex here? Send me a note to discuss multicast routing. Your > Private Network Services client said "Huh?" when asked about setting me up > for multicast. I asked this of them during the most recent meeting and received this in reply: > Steve, > > Mbone is not supported robustly enough by the versions of Cisco IOS that > DIGEX runs on our core routers. We run standard unicast packages, and > multicast support is not in demand enough to see stable releases. > Additionally, bandwidth problems with current multicast routing structures > are high enough to warrant additional waiting before we implement this > service across our backbone after software stability has been achieved. > > Let us know if you have any questions. > > Richard White, Shift Mgr. > Business Connectivity Technical Support -- Steve Hultquist, Chief Technology Officer HSAnet providing high-speed Internet access Boulder, Colorado mailto:ssh@HSAnet.net +1.303.581.0800 http://www.HSAnet.net/

2 1

Re: Smurfing
by Steve Hultquist 13 Feb '98

13 Feb '98

Havard, --On Friday, February 13, 1998, 11:45 PM +0100 Havard.Eidnes(a)runit.sintef.no wrote: > getting Smurfing "under control" takes two things: > > o All router administrators on the immediately reachable > Internet needs to turn off directed broadcasts on their router > interfaces. > o Making sure source IP address spoofing isn't as easily done as > it is now. Also an easy one, right? ;-) I agree, and this is what we have done. The earlier post (from someone else) was asking about how to filter *outbound* directed broadcasts, and I didn't understand how this could be done. A number of my NANOG colleagues have adamantly agreed that it can't! > o While we struggle with the above two, at least some service > providers need to become more responsive in tracking these > sort of events back to their real source. No names mentioned, > none forgotten. Agreed. Would it make sense to come up with a cooperative mechanism for this similar to CERT only faster? > o Lastly, I think that better tools are needed to track this > sort of attacks back to their source (?). That would be very difficult, effectively requiring the ability to query routers and ask if they are seeing packets bound for a specific address. I'd love to see some tools that would help us do that, however! -- Steve Hultquist, Chief Technology Officer HSAnet providing high-speed Internet access Boulder, Colorado mailto:ssh@HSAnet.net +1.303.581.0800 http://www.HSAnet.net/

1 0

RA/RV Feeds from RBN
by Jeffrey Payne 13 Feb '98

13 Feb '98

Time to take a moment and describe today's feed from the encoding perspective. We do lots of on-site coverage, and usually bring in a dedicated ISDN for the encoder feed back to the server(s) and out to the network. In UDP mode, our encoder and server can buffer quite deeply (say, 300 seconds) to accommodate some pretty significant network outages. Until today, we couldn't imagine a scenario where this wasn't good enough, but as luck would have it, we were wrong. Fortunately today's net problem was resolved by the end of the general session and Tuesday *should* be much cleaner. On the subject of camera positioning and exposure, we know, it was not good. I think we can pull together a somewhat more coherent set of post-produced presentations with what we have on tape -- we'll find out when we get a look at them. But we should have better cameras, a video switcher, and somewhat better lighting to do this virtual conference thing right. Next meeting? I heard lots of questions on multicast today...here's how it works with RealMedia. If you have decent MBONE connectivity, you'll negotiate multicast when you connect to the audio or video stream. If you don't, the client falls back to unicast UDP mode. If even that fails (say you're behind a firewall), it rolls to TCP mode, and will ultimately resort to HTTP "cloaking" if nothing else works. Users can override the automated fall-back through the preferences dialog if there's a strong preference for a particular mode. Jeffrey Payne, GM Broadcast Operations RealNetworks, Inc.

9 9

Re: Smurfing
by Joe Provo - Network Architect 13 Feb '98

13 Feb '98

> ==>Perhaps some of the folks on NANOG that use equipment other than Cisco > ==>would like to share how they "configure their router for that"? It would > ==>be a nice service to everyone... > > http://www.quadrunner.com/~chuegen/smurf.txt > > It has Bay Networks and Proteon information, and I'm adding Ascend > information as well within the next week. ...and I've given Craig FORE, Livingston and DEC info. I'm looking to get some more CPE-ish vendors out to him as well. > With Ascend, you must filter traffic to the broadcast address. Am I the only one who thinks them not setting the knob to turn this off is nuts? To have to cut filters specific to each address on a case-by case basis is a lot of work that some people won't take on, and clue- challenged custromers will have difficulty with... Joe

1 0

The Cidr Report
by Tony Bates 13 Feb '98

13 Feb '98

This is an auto-generated mail on Fri Feb 13 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 13Feb98 0) General Status Table History ------------- Date Prefixes 290198 50396 300198 50242 310198 49848 010298 49715 020298 49739 030298 49600 040298 49877 050298 49484 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: 2407 Number of ASes announcing only one prefix: 718 (0 cidr, 718 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1044 announced by AS701 1) Gains by aggregating at the origin AS level --- 13Feb98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 691 368 323 46.7% iSTAR Internet, Inc. AS6235 495 252 243 49.1% Intermedia Communications, Inc. AS4293 430 210 220 51.2% IMCI AS174 874 673 201 23.0% Performance Systems International AS816 635 444 191 30.1% UUNET Canada (ASN-UUNETCA-AS4) AS3602 455 304 151 33.2% Sprint Canada Inc. AS3749 202 61 141 69.8% TECNET AS701 1044 931 113 10.8% Alternet AS3336 109 19 90 82.6% Internet Services, Kolumbus proje AS3751 125 48 77 61.6% SNET-AS AS5668 107 40 67 62.6% Century Telephone Inc. AS3804 204 142 62 30.4% WORLDLINX AS2048 154 92 62 40.3% LaNet AS1239 596 534 62 10.4% SprintLink Backbone AS3221 92 33 59 64.1% EENet Autonomous System AS1 840 782 58 6.9% BBNPLANET AS271 110 55 55 50.0% BCNET-AS AS719 519 468 51 9.8% LANLINK autonomous system AS549 214 163 51 23.8% ONET-AS AS3464 115 64 51 44.3% Alabama Research and Education Ne AS1221 263 214 49 18.6% AARNET-AS AS72 84 36 48 57.1% Schlumberger Information Network AS4763 128 80 48 37.5% Telstra New Zealand AS7545 114 69 45 39.5% TPG Internet Pty Ltd AS684 86 42 44 51.2% MBNET-AS AS4740 354 312 42 11.9% ASN-OZEMAIL (Ozemail Pty Ltd) AS2711 97 55 42 43.3% SUNBELT-AS AS7046 130 89 41 31.5% UUNET-CUSTOMER AS3561 897 857 40 4.5% MCI AS852 156 117 39 25.0% CANET-ASN 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 1

Re: Inexperienced Seeks Partner
by Lewis Eatherton 13 Feb '98

13 Feb '98

Yup, I'd say your missing something.... At 08:50 AM 2/13/98 -0500, Adam Rothschild wrote: >> friends and I have a dialup connection to 5 exchange points. We are >> using 33.6 US Robotics Sportster Win-Modems with a linux box running >> gated. We are applying for our own ASN, and we expect to get it soon. > >Winmodems with a Linux box? Last I checked, there was no software driver, >nor was there any intent on developing one (given USR's strict >non-disclosure policies)... Am I missing something here? > > > > > > > Lewis Eatherton Network Architect SegaSoft, Inc 650.654.2318

1 0

SPAM: beware of CRL! you are LOOSING EMAIL and LOOSING CONTACTS
by Steve Carter 13 Feb '98

13 Feb '98

Thought this might interest some of you guys, especially those at CRL and one other fella...... >;) BTW, I am the messenger, not the author..... -Steve. From: dabao38(a)hotmail.com >Subject: beware of CRL! you are LOOSING EMAIL and LOOSING CONTACTS >Date: Fri, 13 Feb 1998 00:21:26 -0600 >Message-ID: <887350032.1587019783(a)dejanews.com> >Newsgroups: >ba.internet,alt.internet,alt.internet.access,alt.internet.commerce,alt. internet. >providers.america,alt.internet.services >Organization: Deja News Posting Service >Path: >news.iswest.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbrid ge.uorego >n.edu!nntp2.dejanews.com!grunt.dejanews.com!not-for-mail >X-Article-Creation-Date: Fri Feb 13 06:07:13 1998 GMT >X-Authenticated-Sender: dabao38(a)hotmail.com >X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 95) >X-Originating-IP-Addr: 207.171.196.242 (sf-pm10-18-242.dialup.slip.net) >Lines: 43 >Xref: news.iswest.net ba.internet:34461 alt.internet:15772 >alt.internet.commerce:62928 alt.internet.providers.america:1533 >alt.internet.services:135128 > >Why C R L SUCKS AND YOU TOO SHOULD DROP THEM: 1) Your email address at >CRL only works with the portion of the world THEY like. Did you know they >block off many servers and all of their users from being able to reach >you because someone onced might have used that machine to send commercial >email? And they will NOT tell you this nor admit to it until you've >mysteriously lost touch with your contacts and loved ones. A few >examples: kiss your love ones goodbye from hotmail.com, juno.com, >hinet.net (this would be the entire nation for Taiwan). They say they are >doing this to fight spam, ironically a lot of spam is actually generated >from CRL. More like kissing up to this self appointed Internet Lord Paul >Vixie who runs the Real Time Blackhole List (the list which does this >emai censoring and blocking, with out any concern for end users' >connectivity). This guy prettymuch figured he has the power to decide who >you can and can not get email from. And they are banking on you NOT >FINDING OUT about it. And guess what, my spam has not decreased, but >actually increased since they used this none-selective block.. they did >managed to cut me off from my important contacts, but not spam. 2) Try >it. Their Dial up in San Francisco and Southbay hang up on you or do not >answer 70% of the time during prime time and 50% during off peak (this >was my experience, not scientific.. but still). They refuse to upgrade >beyond 28.8k (spending all the money they made on the fat corporate job >hogs). 3) Tech support? What tech support? When I confronted them about >the missing email they actually yelled at me (after 10-15 emails to get a >response, phone calls? forget it..) and told me it was my contacts' fault >that they subscribed to the "bad, bad spamming company for ISP). Imagin >if your phone company told you you can not get calls from your mom >because she lives in an area with a phone company they did not like.. >Since when did CRL figure out dictatorship was in again? 4)They will NOT >cancel your service and will keep on charging your credit card... Many >other users complained about this, it was even mentioned in PC Magazine's >ISP review. There are many more reasons why they bite, but I really do >not want to waste my energy over those bastards anymore. I am actually >the last of my associates to drop their service because I do not want to >change my email and web address for the sake of business (I've already >spent a lot on printing them on all kinds of materials). Face it, CRL has >gotten fat off of it's customers, now it is screwing them. The email >block was what really did it. How would you like a phone service >(especially for business) that can only take calls from a PART of the >country and the world? Email me if you want to start a class action >lawsuit against them. > >-------------------==== Posted via Deja News ====----------------------- > http://www.dejanews.com/ Search, Read, Post to Usenet

2 1