- Test - lists.nanog.org

the whole world disappeared?
by Rob M VanHooren 13 Apr '98

13 Apr '98

Anyone have details on AT&T tkt# 841-302-457? Apparently 75% of all Canada/US cross-border just fell over and died. I've got Frame and T's *and* 800/888 voice circuits that just went for a nosedive. Nobody's saying squat. Anyone with a clue or ETA? Who dropped a bomb or something? Is it just AT&T? I tried Sprint and MCI's NOCs; they are both also "experiencing heavy call volume" and that might be a clue it's bigger than just one IXC. And I wanted to go home on time (ie. before midnight). Sheesh. I know, I know, it's my fault -- I chose this as a career :-)) Anyone with a clue, drop us a note? w/thx. --R. PS: yes, yes, this really should have gone to outage-discuss. Sorry... ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-.._..-*~ Rob M. VanHooren - Chief Plumber, +1 519 679-1155 x33 Packet Pusher, and Resident Mad Scientist(tm) Alarms to 646-4724 Network Engineering Services 171 Queens Avenue, Suite 320 Linkdata Communications Inc. London, CANADA

4 3

[postmaster@mobilelogic.com: Undeliverable: SMURF amplifier block list]
by Jay R. Ashworth 13 Apr '98

13 Apr '98

Three copies of this to owner-nanog in the last week have gone undealt with. Perhaps this will solve the problem? -----Forwarded message from System Administrator <postmaster(a)mobilelogic.com>----- Received: from nomad.wiretel.com (firewall-user(a)nomad.wiretel.com [206.83.100.2]) by scfn.thpl.lib.fl.us (8.8.5/8.6.5) with ESMTP id QAA03143 for <JRA(a)SCFN.THPL.LIB.FL.US>; Mon, 13 Apr 1998 16:37:36 -0400 (EDT) Received: by nomad.wiretel.com; id PAA26731; Mon, 13 Apr 1998 15:31:40 -0600 (MDT) Received: from unknown(206.83.100.36) by nomad.wiretel.com via smap (3.2) id xma026729; Mon, 13 Apr 98 15:31:36 -0600 Received: by masai.wiretel.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BD66E9.D56E4A30(a)masai.wiretel.com>; Mon, 13 Apr 1998 14:38:33 -0600 Message-ID: <01BD66E9.D56E4A30(a)masai.wiretel.com> From: System Administrator <postmaster(a)mobilelogic.com> To: <JRA(a)SCFN.THPL.LIB.FL.US> Subject: Undeliverable: SMURF amplifier block list Date: Mon, 13 Apr 1998 14:38:33 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Your message did not reach some or all of the intended recipients. To: DCHADWICK(a)mobilelogic.com Subject: SMURF amplifier block list Sent: 4/13/98 14:38:33 PM The following recipient(s) could not be reached: DCHADWICK(a)mobilelogic.com on 4/13/98 14:38:33 PM Recipient Not Found MSEXCH:IMC:WTI:MobileLogic:MASAI -----End of forwarded message----- <ahem> Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com

1 0

SMURF amplifier block list
by Karl Denninger 13 Apr '98

13 Apr '98

The following networks and masks are banned from our network at the core due to being smurf amplifiers. When the folks who own these STOP THIS, we'll take them off the list. Contact me by TELEPHONE if you want to discuss this matter or what a Smurf is and why you should care. I'm going to start posting the blacklist here weekly in the hopes that peer pressure will cause people to clean up their acts. Until you DO clean up your act, you're not transiting our network - period. We're not going to accept this kind of vandalism and attractive nuisance any more. If you haven't disabled directed broadcast forwarding, you are a potential listee on this blacklist. DO IT NOW, or risk connectivity blockades. I urge all other network providers to block any identified smurf amplifier that they can verify, and to post their list as well. Only through public pressure can people be forced to CORRECTLY configure their networks to make these attacks impossible to launch. access-list 2 deny 128.118.0.0 0.0.255.255 access-list 2 deny 129.24.0.0 0.0.255.255 access-list 2 deny 129.111.0.0 0.0.255.255 access-list 2 deny 129.100.0.0 0.0.255.255 access-list 2 deny 128.40.0.0 0.0.255.255 access-list 2 deny 129.101.0.0 0.0.255.255 access-list 2 deny 203.64.0.0 0.0.255.255 access-list 2 deny 129.115.0.0 0.0.255.255 access-list 2 deny 203.108.225.0 0.0.0.255 access-list 2 deny 129.60.0.0 0.0.255.255 access-list 2 deny 137.79.0.0 0.0.255.255 access-list 2 deny 130.37.0.0 0.0.255.255 access-list 2 deny 130.70.0.0 0.0.255.255 access-list 2 deny 203.108.236.0 0.0.0.255 access-list 2 deny 132.169.0.0 0.0.255.255 access-list 2 deny 129.107.0.0 0.0.255.255 access-list 2 deny 129.49.0.0 0.0.255.255 access-list 2 deny 129.96.0.0 0.0.255.255 access-list 2 deny 130.65.0.0 0.0.255.255 access-list 2 deny 134.205.0.0 0.0.255.255 access-list 2 deny 129.29.0.0 0.0.255.255 access-list 2 deny 204.48.224.0 0.0.0.255 access-list 2 deny 205.177.49.0 0.0.0.255 access-list 2 deny 204.47.208.0 0.0.0.255 access-list 2 deny 204.242.172.0 0.0.0.255 access-list 2 deny 194.6.129.0 0.0.0.255 access-list 2 deny 206.31.78.0 0.0.0.255 access-list 2 deny 207.211.60.0 0.0.0.255 access-list 2 deny 206.27.242.0 0.0.0.255 access-list 2 deny 207.175.67.0 0.0.0.255 I'm sure there are more, but these are the ones blacklisted in our network configuration right now. -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

11 19

Strange behavior...
by Aaron Tavistock 13 Apr '98

13 Apr '98

Not too sure if this falls into NANOG or not but I thought I'd give it a shot. I'm seeing some wierd responses from the Sprintlink primary name server (ns1.sprintlink.com) and I wanted to know if anyone could explain the behavior. Pinging 204.117.214.10 from San Francisco CA (GTE & Pacbell) and our colo in Bay City MI (MCI), I get a standard response. However, if I ping from our colo in Cambridge MA (GTE), I get a response of "2 times amplification" instead of packet loss. I've certainly seen amplification from ping in the past, but I thought it was a host/interface configuration issue that would affect all external hosts equally. I did not believe it had anything to do with routing, but now I'm not so sure. Anyone have any clues on why this is happening? Can anyone explain why ICMP amplification would occur? Aaron Tavistock Network Engineer / UNIX Systems Administrator Total Entertainment Network (http://www.ten.net)

3 2

someone new to sanction: wwd.org & comsys2.com
by Erik E. Fair 13 Apr '98

13 Apr '98

Western World Distribution (WWD3-DOM) 5751-246 B street Langley, BC v2z1h2 CA Domain Name: WWD.ORG Administrative Contact: Proske, Sean (SP1745) mail(a)WWD.ORG (604) 856-9330 (FAX) (604) 856-9330 Technical Contact, Zone Contact: Jarman, Greg (GJ267) greg(a)COMSYS.NET 3179322083 Billing Contact: Proske, Sean (SP1745) mail(a)WWD.ORG (604) 856-9330 (FAX) (604) 856-9330 Record last updated on 26-Aug-97. Record created on 24-Dec-96. Database last updated on 13-Apr-98 03:38:23 EDT. Domain servers in listed order: NS.COMSYS.NET 206.230.41.2 RESUME1.COM 206.230.41.224 Indiana Comm. and Sys (COMSYS6-DOM) 240 North Main Rushville, IN 46173 US Domain Name: COMSYS2.COM Administrative Contact, Technical Contact, Zone Contact: Jarman, Greg (GJ267) greg(a)COMSYS.NET 3179322083 Billing Contact: Jarman, Greg (GJ267) greg(a)COMSYS.NET 3179322083 Record last updated on 29-Mar-97. Record created on 29-Mar-97. Database last updated on 13-Apr-98 03:38:23 EDT. Domain servers in listed order: NS.COMSYS.NET 206.230.41.2 RESUME1.COM 206.230.41.224 ---- BEGIN FORWARDED MESSAGE Received: from NO-IDENT-SERVICE(a)homeworld.cygnus.com (port 53339 [205.180.83.70]) by cesium.clock.org with SMTP id <77318-247>; Mon, 13 Apr 1998 04:10:33 -0700 Received: (qmail 4611 invoked by uid 605); 13 Apr 1998 11:10:09 -0000 Received: (qmail 4562 invoked from network); 13 Apr 1998 11:10:04 -0000 Received: from unknown (HELO comsys2.com) (www(a)206.230.41.123) by homeworld.cygnus.com with SMTP; 13 Apr 1998 11:10:04 -0000 Received: =?UNKNOWN-8BIT?Q?=9Cby?= tallas4112.com (8.8.5/8.8.5) id GAA25409 for current-users(a)NetBSD.ORG; Mon, 13 Apr 1998 06:09:44 -0500 (EST) Date: Mon, 13 Apr 1998 06:09:44 -0500 (EST) Message-Id: <199804131109(a)tallas4112.com> From: bulkisp(a)wwd.org Reply-To: bulkisp(a)wwd.org To: current-users(a)NetBSD.ORG Subject: BULK ISP Sender: current-users-owner(a)NetBSD.ORG Precedence: list Delivered-To: current-users(a)NetBSD.ORG Return-Path: <current-users-owner-netbsd-current-users-local=clock.org(a)NetBSD.ORG> X-UIDL: 0325d4f5085c143d8a376734021769ba Hi, I noticed your listing for Bulk Email Software in the search engines and I thought you may have a need for a Bulk Friendly ISP. For complete details regarding our services, please visit our website at http://wwd.org Best regards, Sean PS: We are initially taking on only 100 users so don't delay... space is limited. ---- END FORWARDED MESSAGE

1 0

Re: SMURF amplifier block list
by shields＠crosslink.net 13 Apr '98

13 Apr '98

In article <Pine.BSI.3.93.980412085359.7879a-100000(a)sidhe.memra.com>, Michael Dillon <michael(a)memra.com> wrote: > If Karl will supply us the IP address of a non-critical machine in his > network then we only need one list maintained. Anyone can then add new > networks to Karl's list simply by smurfing his non-critical machine and it > will still meet his criteria of a verified atack. Careful. I could, from a well-connected machine, launch a stream of forged ICMP echo replies from various 199.166.227.x addresses. This would cause it to look like junction.net was the source of a smurf, and cause them to be blocked. Well, in the case of junction.net, there is no such forgery needed. ~$ host www.memra.com www.memra.com A 199.166.227.56 ~$ ping 199.166.227.255 PING 199.166.227.255 (199.166.227.255): 56 data bytes 64 bytes from 134.87.109.226: icmp_seq=0 ttl=243 time=110.2 ms 64 bytes from 199.166.227.41: icmp_seq=0 ttl=51 time=111.0 ms (DUP!) 64 bytes from 199.166.227.32: icmp_seq=0 ttl=242 time=112.2 ms (DUP!) 64 bytes from 199.166.227.54: icmp_seq=0 ttl=51 time=112.8 ms (DUP!) 64 bytes from 199.166.227.5: icmp_seq=0 ttl=51 time=113.7 ms (DUP!) 64 bytes from 199.166.227.27: icmp_seq=0 ttl=51 time=114.3 ms (DUP!) 64 bytes from 199.166.227.22: icmp_seq=0 ttl=51 time=115.0 ms (DUP!) 64 bytes from 199.166.227.1: icmp_seq=0 ttl=51 time=115.7 ms (DUP!) 64 bytes from 199.166.227.12: icmp_seq=0 ttl=242 time=116.4 ms (DUP!) 64 bytes from 199.166.227.19: icmp_seq=0 ttl=51 time=117.0 ms (DUP!) 64 bytes from 199.166.227.21: icmp_seq=0 ttl=242 time=117.7 ms (DUP!) 64 bytes from 199.166.227.28: icmp_seq=0 ttl=51 time=118.3 ms (DUP!) 64 bytes from 199.166.227.26: icmp_seq=0 ttl=242 time=119.0 ms (DUP!) --- 199.166.227.255 ping statistics --- 1 packets transmitted, 1 packets received, +12 duplicates, 0% packet loss round-trip min/avg/max = 110.2/114.8/119.0 ms -- Shields, CrossLink.

6 5

NANOG topics so far
by Susan Rebecca Harris 13 Apr '98

13 Apr '98

Greetings - here are topics we've lined up so far for the June NANOG: - Differentiated Services Panel: Working Group Update and Viewpoints From the Community (Kathleen Nichols, Bay Networks, moderator) - The National Internet Measurement Information (NIMI) Project (Vern Paxson, Laurence Berkely Lab) - Scaling BGP (Yakov Rekhter, Cisco) - ARIN Update (Kim Hubbard, ARIN) - InterNIC Update (Mark Kosters, InterNIC) - Path and Round-Trip Time Measurements: a New Project at CAIDA (Daniel McRobb) - Implementing Simplex IP Bandwidth Augmentation and IP-Based News and HTTP Broadcast Services via Geosynchronous Satellite (Avi Freedman, Net Access) - Introduction to the NETPERF.NET Inter-Provider Network Performance Monitoring Project (Avi Freedman, Net Access) Additional presentations will be posted at www.nanog.org . Are there other topics you'd like to hear about? ------------------------------------------------------------------------- Susan Rebecca Harris, Ph.D. Merit Network, Inc. Phone: 734.936.2100 srh(a)merit.edu Senior Science Writer Fax: 734.647.3185 -------------------------------------------------------------------------

1 0

Re: SMURF amplifier block list
by Chris Liljenstolpe 13 Apr '98

13 Apr '98

Greetings, I was just thinking the same thing. In general, I hate (as I'm sure everyone else here does as well) cutting connectivity, but this appears to be the only way to fix the problem. The RBL (or something architected like it) would be a very clean way of doing it.... Chris --On Sunday, 12 April, 1998, 00:54 -0400 "Jon Lewis" <jlewis(a)inorganic5.fdt.net> wrote: > On Sat, 11 Apr 1998, Sean M. Doran wrote: > >> And consequently increases the liklihood that more networks >> will refuse traffic to or from these networks, which in turn >> increases the pressure on these sites to wonder what is happening >> to their connectivity and how to repair it. Which may just solve >> the problem. >> >> This is a monumental admission: I think Karl is doing the right thing. > > Would the vix people have any interest in just adding "being a smurf amp" > to the possible causes for entry in the BGP version of RBL? That way, it > would be harder for the smurf d00dz to get up to date lists. > > I suggested this sort of thing a while ago, but don't currently have time > to implement it. The vix people already have everything in place. > > ------------------------------------------------------------------ > Jon Lewis <jlewis(a)fdt.net> | http://noagent.com/?jl1 for cheap > Network Administrator | life insurance over the net. > Florida Digital Turnpike | > ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____ CChris Liljenstolpe - Principal Engineer - worldwide solutions, Inc. Currently under contract to the US Antarctic Prog., McMurdo Stn. Antarctica mailto:cds@wwsi.com http://www.wwsi.com TEL(303)-581-0800 FAX(303)-530-0191 worldwide solutions, Inc. Ste 100, 4450 Arapahoe Ave, Boulder CO, 80303 USA

1 0

Re: Fixing RFC's WAS Re: SMURF amplifier block list
by Scott Bradner 13 Apr '98

13 Apr '98

-- > Is there a review of the Router and Host requirements RFC's in the works? > Specifically, to review those areas which could be changed to fix some of > these problems. -- There are a number of RFCs that it would be good to update (I'd point to 1122 & 1123 before RR) but it takes someone with lots of time and energy to take on one of these big ones - if you know of someone who is willing to do the work and has the time a number of us on the IESG would love to know. Scott

2 1

Re: [nanog] Re: SMURF amplifier block list
by Sean M. Doran 13 Apr '98

13 Apr '98

Uhm, all that is necessary is for Karl to tell people what he's blocking on his network in such a way that anyone else wanting to protect themselves in the same way can so configure their routers. Ironically, this closely parallels the Satanic Phyltres, with similar sets of plusses and minuses. The idea of some permanent coordination is disconcerting in two ways: firstly, it assumes that the problem is permanent (which I doubt), and secondly, the idea of there being a central administration for policing the network seems to to be incompatible with the theory that the Internet is fundamentally ungovernable. Essentially, if "they" shouldn't bother to try, because it won't work, why should "we" bother to try? Sean.

1 0