- NANOG - lists.nanog.org

Internet Data Center Notes from NANOG14
by William B. Norton 25 Nov '98

25 Nov '98

Hi all - Thanks to everyone who participated in the Internet Data Center BOF at NANOG 14. As promised, I wrote down the items folks contributed to the white boards and tried to add some context to them. Since folks added stuff to the lists when we moved upstairs-I wasn't involved in the discussion and the notes are my best guess at your additions. Corrections/clarifications welcome. Here is the URL: http://www-personal.umich.edu/~wbn/DataCenterNeedsNotes.htm It would be good to turn these notes into better prose for the community that intend on building/contracting/choosing facilities for housing Internet gear. Let me know if you'd like to help write that up. Cheers - Bill

1 0

Re: About last smurf floods - additional info
by Paul Ferguson 25 Nov '98

25 Nov '98

At 04:25 PM 11/25/98 +0300, Alex P. Rudnev wrote: >You are not right, everything should be done - clearing trojans from your >servers, filtering frauded SRC addresses (most important issue), >decreasing SMURF amplifyers, lawsuits agains the hackers. It's amazing, >but we have not ANY official complain from foreign countries (foreign >companies) through I have asked such complain any time I'v write about >the broken system/network. As aside, ingress filtering (a la RFC2267) or unicast RPF checks work quite well in filtering out traffic originating from bogons. Both of these are relatively simple to invoke. The key issue here is that (it appears that) some networks are not taking "socially responsible" actions beacuse of either (a) laziness, (b) ignorance, or (c) both. - paul

1 0

About last smurf floods - additional info
by Alex P. Rudnev 25 Nov '98

25 Nov '98

I am not sure if it's just those SMURF attack someone write about yesterday, but in accordance to my information: - there was 3 or 4 SMURF attacks againts .PSU.EDU servers. May be, some of them was forwarded to DAL.NET because it's IRC server and all (ALL) this attacks was done to show _I am very BIG and you are NOTHING_ in IRC conversation, or _I have 10 shells in XXX.GOV and you have not_ or _My shells are better than yours_. - the server engr-mis-01.cedcc.psu.edu was broken and abused by the hacker. Through it's suspection only. - the hackers have used some accounts in NASA to provide SMURF. Unfortunately, I can't contact anyone from NASA in a few weeks and if someone can give me contact e-mail it'll be appresiated. Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

2 2

Smurf attack in progress - FIX YOUR RELAYS NOW
by Dalvenjah FoxFire 25 Nov '98

25 Nov '98

Hi folks, Since Sunday, I've e-mailed, telephoned, and contacted the folks responsible for the networks involved in the current smurf against my network. Since then, a grand total of four (count 'em, *four*) have responded and shut off broadcasts. Here are the networks that have ignored me so far. If you are a contact for them, if you know the contact for them, peer with them, talk to them on the golf course, whatever - get them out of bed, wake them up, and get them to fix their routers *NOW*. If you are their uplink, block their traffic or otherwise disconnect them until they fix their routers. This is ridiculous, folks. I'm seeing networks that are customers of UUnet, Sprint, MCI/C&W, Telia, all the big ISPs that are STILL smurf amplifiers two years after we knew about the attack and how to fix it. Note, I am sending this to nanog because none of these people have responded or fixed their networks for *TWO DAYS* now. How do you configure your router for this? Insert an ACL to deny connectivity to these people until they fix their routers to not relay. If you do happen to fix one of these networks, or if perhaps you can backtrace the smurf destined for 209.133.28.69, please e-mail me back or telephone me; my phone# is in whois. -dalvenjah #0 - Probable Smurf attack detected from 206.173.226.0/24 (1028 bytes) Concentric Research Corp. (NETBLK-CONCENTRIC-BLK) 10590 N. Tantau Ave. Cupertino, CA 95014 Concentric Networks. #1 - Probable Smurf attack detected from 198.145.32.0/24 (1028 bytes) Extensis Corporation (NETBLK-AUSNET-US-EXTEN) 55 SW Yamhill, Floor 4 Portland, OR 97204 USA C&W/World.net customer #2 - Probable Smurf attack detected from 206.136.9.0/24 (1028 bytes) Primary Access Corporation (NET-PRIACC2) 12230 World Trade Drive San Deigo, CA 92128-3765 US UUnet customer #3 - Probable Smurf attack detected from 194.16.2.0/24 (1028 bytes) inetnum: 194.16.2.0 - 194.16.2.255 netname: NETCH descr: Netch Technologies AB country: SE admin-c: HD26-RIPE tech-c: SN38-RIPE Telia customer #4 - Probable Smurf attack detected from 143.224.103.0/16 (1028 bytes) Joanneum Research (NET-JR-NETWORK) A-8010 Graz Steyrergasse 17 AUSTRIA AGIS/Loralorion.net customer. #5 - Probable Smurf attack detected from 204.151.131.0/24 (1028 bytes) ANS CO+RE Systems, Inc. (NETBLK-ANS-C-BLOCK3) 100 Clearbrook Road Elmsford, NY 10523 ANS/BCtel/AGT.net customer #6 - Probable Smurf attack detected from 195.67.69.0/24 (1028 bytes) inetnum: 195.67.69.0 - 195.67.69.31 netname: PROFFICE descr: Proffice Ab country: SE admin-c: MH1035-RIPE tech-c: MH1035-RIPE Telia customer #7 - Probable Smurf attack detected from 199.185.220.0/24 (1028 bytes) ED TEL (NETBLK-EDTEL-PLANET) Edmonton, AB; T5J 2R4 CA BCtel/AGT.net customer -- Dalvenjah FoxFire (aka Sven Nielsen) "Life is anything that dies when Founder, the DALnet IRC Network you stomp on it." -Dave Barry e-mail: dalvenjah(a)dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/

2 1

mae-east-atm?
by dlr＠bungi.com 25 Nov '98

25 Nov '98

Is there anyone actually live on the mae-east-atm? What's the performance like, so far? -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

Re: Black Hole Vixie/RBL
by owen＠DeLong.SJ.CA.US 25 Nov '98

25 Nov '98

The price of liberty is putting up with the occasional kook. > who let the kook in? > > On Thu, 7 Feb 2036, Bob Allisat wrote: > While I don't agree with the kook, and I do agree with you that he is a kook, free speach sez the kooks have the right to talk too. Owen

1 0

RE: Router gets hurt!
by Eric Germann 24 Nov '98

24 Nov '98

You may also wish to implement WINS so it doesn't use broadcast name resolution techniques. Also, if you have any WfWg machines, there was a fix years ago where they wouldn't relinquish a master browser role. MS issued a fix back in the 3.51 days. Similar situation, election wars, although it never took out Cat 5's or 7206's on the networks we used. Surely you're not doing broadcast flooding on the Crisco, are you? Alternatively, you can force one machine to be the master browser and the others to be backup browsers which pretty much obviates the need for an election. I would suggest http://support.microsoft.com and search for Preferred Master Browser. Eric ---"James D. Wilson" wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I think you mean "browse master" and if your switches are falling > apart by browser elections you probably have more serious problems on > your network than NetBios traffic (however odorous it may "smell".) > I'd take a good look at your spanning tree configuration and > statistics on your switches. You could also be running into problems > with bdpu traffic confusion in your switches spanning tree if you are > also bridging and your bridge group priority 0 is not on your local > side of your bridge group. > > - -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Jason Weisberger > Sent: Monday, November 23, 1998 8:02 PM > To: nanog(a)merit.edu > Subject: Router gets hurt! > > > > Discovered today that NT has the built in ability to drown your > network > and stomp on the routers cpu. Seems if someone sets up 2 NT domain > masters > or whatever that Netbios garbage is called, they attempt to "hold an > election." The election is comprised of slamming every machine it can > find > and then every broadcast address it can think of with udp on port 137. > > After a few minutes of it an RSP4 gets real tired and you start losing > packets as well as the switches all falling apart after trying to > forward > the zillion mbits/sec of useless data. > > Anyone else seen anything like this? > > - -- > Jason Weisberger > Chief Technology Officer > SoftAware, Inc. 310/305-0275 > > > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 5.5.5 for non-commercial use <http://www.nai.com> > Comment: All Spammers Are Thieves - Jail Them Now > > iQA/AwUBNlpUyzAufbtGOmgdEQKO9ACg7UU/L9En2tkEbQkvINeAkGq0m1sAoJZy > YVC8jBkQfTn46xdhNduWEPOo > =fPj2 > -----END PGP SIGNATURE----- > > > > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

RE: SOLVED! The cause of puzzling TCP (eg. WHOIS) connection fai lures with some InterNIC.net hosts
by Chris Mauritz 24 Nov '98

24 Nov '98

Actually, this isn't a BigIP problem. It's a BSDI problem (the underlying OS for the BigIP box). I believe BSDI has a patch available for BSD/OS 4.0 (mayabe even 3.1). While you can't benefit from this patch directly, you can perhaps nudge your F5 rep about expediting a patch for your boxen. Chris Chris Mauritz Director, Systems Administration Rare Medium, Inc. chrism(a)raremedium.com -----Original Message----- From: Mark Kosters [mailto:markk@internic.net] Sent: Tuesday, November 24, 1998 11:08 AM To: Greg A. Woods; North America Network Operators Group; NetBSD Networking Technical Discussion List Cc: Mark Kosters Subject: Re: SOLVED! The cause of puzzling TCP (eg. WHOIS) connection failures with some InterNIC.net hosts On Fri, Nov 20, 1998 at 04:25:11PM -0500, Greg A. Woods wrote: > The problem has to do with the failure of a host to fragment larger > packets on demand (i.e. when the other host sends an ICMP "needs frag" > notification). This may be because the ICMP packet never gets through > (perhaps someone who didn't understand TCP/IP and ICMP and everything > else related implemented a filter on all "abnormal" ICMP packets); or it > may be because the receiving host doesn't understand the ICMP "needs > frag" request (and also doesn't implement path MTU discovery, or have I > got that backwards?). > > No matter what the problem really is, I'm sure a *lot* of people would > be much happier if this problem were fixed, specifically for the WHOIS > service (though I've also had troubles receiving HTTP too). I got quite > a few replies about similar experiences when I first posted about this > on NANOG recently. Thanks Greg for the good information. The InterNIC load balancers (BigIP made by F5 Labs) do have a problem with path MTU discovery. We have taken a short term fix of turning off path MTU discovery on the hosts behind BigIP until F5 issues a fix. Regards, Mark -- Mark Kosters markk(a)internic.net InterNIC Registration Services PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48 I am not a spokesperson for NSI. Anything I write or say is my personal opinion and in no way should be interpreted as NSI's official position.

1 0

SOLVED! The cause of puzzling TCP (eg. WHOIS) connection failures with some InterNIC.net hosts
by woods＠most.weird.com 24 Nov '98

24 Nov '98

[[ NOTE: this message is cross-posted to NANOG and tech-net, as well as Cc'ed to Mark Kosters (because I don't know if Mark reads either list). Please reply either directly to me, or to *one* of those lists as appropriate (it's probably not relevant to discuss on NANOG now that the problem has been identified unless it's a problem with some particular piece of equipment, in which case it would be good to identify it so others can fix similar problems. ]] I've discovered the cause of those problems with TCP connections to/from some InterNIC.net hosts (and some other hosts, one of which was trying to send me e-mail and thus necessitated that I debug it in more detail). Now that I know the cause I can say that this problem is usually indicative of a firewall with a non-compliant TCP/IP implementation, though it may also indicate an unwise firewall filtering policy too. The problem has to do with the failure of a host to fragment larger packets on demand (i.e. when the other host sends an ICMP "needs frag" notification). This may be because the ICMP packet never gets through (perhaps someone who didn't understand TCP/IP and ICMP and everything else related implemented a filter on all "abnormal" ICMP packets); or it may be because the receiving host doesn't understand the ICMP "needs frag" request (and also doesn't implement path MTU discovery, or have I got that backwards?). No matter what the problem really is, I'm sure a *lot* of people would be much happier if this problem were fixed, specifically for the WHOIS service (though I've also had troubles receiving HTTP too). I got quite a few replies about similar experiences when I first posted about this on NANOG recently. Here's a sample trace collected from the PPP router upstream which shows the outgoing ICMP packets and the incoming TCP retransmissions, un-fragmented, even after the first request to fragment: 15:02:56.097980 204.92.254.2.4721 > 198.41.0.6.43: S 1660910424:1660910424(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 5148233 0> (ttl 62, id 25948) 15:02:56.420273 198.41.0.6.43 > 204.92.254.2.4721: S 1062510833:1062510833(0) ack 1660910425 win 8760 <mss 1460> (DF) (ttl 245, id 4189) 15:02:56.674783 204.92.254.2.4721 > 198.41.0.6.43: . ack 1 win 17520 (ttl 62, id 25951) 15:02:56.677143 204.92.254.2.4721 > 198.41.0.6.43: P 1:6(5) ack 1 win 17520 (ttl 62, id 25952) 15:02:57.175854 198.41.0.6.43 > 204.92.254.2.4721: . ack 6 win 8760 (DF) (ttl 245, id 4190) 15:02:59.393169 198.41.0.6.43 > 204.92.254.2.4721: P 1:4(3) ack 6 win 8760 (DF) (ttl 245, id 4191) 15:02:59.532326 204.92.254.2.4721 > 198.41.0.6.43: . ack 4 win 17517 (ttl 62, id 25994) 15:03:00.326761 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 4192) 15:03:00.327688 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19390) 15:03:00.420416 198.41.0.6.43 > 204.92.254.2.4721: . 1464:2914(1450) ack 6 win 8760 (DF) (ttl 245, id 4193) 15:03:00.421157 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19391) 15:03:03.381245 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 4194) 15:03:03.382120 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19392) 15:03:10.619116 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 4195) 15:03:10.620110 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19411) 15:03:24.974732 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 4196) 15:03:24.975626 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19413) 15:03:53.941690 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 4197) 15:03:53.942656 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19418) 15:04:50.256764 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 52333) 15:04:50.257959 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19425) 15:05:46.509834 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 43047) 15:05:46.510716 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19433) 15:06:29.615496 198.41.0.6.43 > 204.92.254.2.4721: R 4:4(0) ack 6 win 0 (ttl 55, id 23874) Note that ICMP packets get through correctly, seemingly because NetBSD fragments them on the way through (I suppose a "needs frag" packet could be sent in this case too, but that does seem a little too intertwined to be reliable). Here's the trace of two big (-s 1400) packet pings from the router's POV: 15:17:21.092624 204.92.254.2 > 198.41.0.6: icmp: echo request (ttl 253, id 41845) 15:17:21.366494 198.41.0.6 > 204.92.254.2: icmp: echo reply (ttl 246, id 25176) 15:17:21.978679 204.92.254.2 > 198.41.0.6: icmp: echo request (ttl 253, id 41855) 15:17:22.227824 198.41.0.6 > 204.92.254.2: icmp: echo reply (ttl 246, id 25351) And here's what I see on my end of the link corresponding to the above: 15:17:17.466591 204.92.254.2 > 198.41.0.6: icmp: echo request (ttl 255, id 41845) 15:17:18.467986 204.92.254.2 > 198.41.0.6: icmp: echo request (ttl 255, id 41855) 15:17:18.487006 198.41.0.6 > 204.92.254.2: icmp: echo reply (frag 25176:984@0+) (ttl 244) 15:17:18.489940 198.41.0.6 > 204.92.254.2: (frag 25176:24@984) (ttl 244) 15:17:19.251136 198.41.0.6 > 204.92.254.2: icmp: echo reply (frag 25351:984@0+) (ttl 244) 15:17:19.263880 198.41.0.6 > 204.92.254.2: (frag 25351:24@984) (ttl 244) Perhaps routers (i.e. NetBSD when it's routing, in this case) should also fragment TCP packets on the way through if there are "too many" retransmissions of over-sized packets (one's too many for me, but I guess on high-latency links there might be two or three in the pipe -- perhaps a timer would help adjust when to do local fragmenting). -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods(a)acm.org> <robohack!woods> Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com>

5 5

NSI policy on lame delagations
by Patrick Greenwell 24 Nov '98

24 Nov '98

Seems that NSI has a new policy on lame delagations. I never heard anything about this. Anyone else? /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell (800) 299-1288 v CTO (925) 377-1212 v NameSecure (925) 377-1414 f Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ ---------- Forwarded message ---------- Date: Fri, 20 Nov 1998 12:17:26 -0500 From: Chuck Gomes <cgomes(a)internic.net> Reply-To: cgomes(a)NETSOL.COM To: DOMAIN-POLICY(a)LISTS.INTERNIC.NET Subject: Re: Missing DNS servers When we become aware of a lame delegation, we remove the name servers and notify the registrant that they have a limited time to provide name servers. If name service is not provided, we delete the name. In the interim the record would show as you see below. Chuck Gomes -----Original Message----- From: Tony Cognata [mailto:yett@BRIO.YIKES.COM] Sent: Friday, November 20, 1998 11:57 AM To: DOMAIN-POLICY(a)LISTS.INTERNIC.NET Subject: Missing DNS servers I would hope that someone working at Network Solutions would know the answer to this question. Why would the "whois" record for a domain called ANSHAN.COM not show a primary and secondary DNS server? Here is the record for the domain: Spearmind Communications MK (ANSHAN7-DOM) Effnerstr. 1e Ingolstadt, Bayern 85049 DE Domain Name: ANSHAN.COM Administrative Contact: Koch, Mario (MK5132) mario.koch(a)USA.NET +49-841-483843 (FAX) +49-201-247180-10447 Technical Contact, Zone Contact: Hostmaster, TABNet (TH941) TABNETHOSTMASTER(a)TABNET.NET 707 256-1999 (FAX) 707 256-1997 Billing Contact: Koch, Mario (MK5132) mario.koch(a)USA.NET +49-841-483843 (FAX) +49-201-247180-10447 Record last updated on 25-Mar-98. Record created on 26-Jan-98. Database last updated on 13-Oct-98 06:21:01 EDT. No known domain servers. --- You'll note that the very last line of the record shows that no DNS servers exist for the domain. The sentence "No known domain servers" appears. Also, on rare occasions I have come across "whois" records for domains that show only one DNS server appearing, not the customary (and required) two. Just curious to know what might be happening in these cases? Thank you. -- DOMAIN-POLICY administrivia should be sent to <listserv(a)lists.internic.net> To unsubscribe send a message with only one line "SIGNOFF DOMAIN-POLICY" For more help regarding Listserv commands send the one line "HELP" -- DOMAIN-POLICY administrivia should be sent to <listserv(a)lists.internic.net> To unsubscribe send a message with only one line "SIGNOFF DOMAIN-POLICY" For more help regarding Listserv commands send the one line "HELP"

14 32