- NANOG - lists.nanog.org

Smurf Prevention
by Richard Thomas 12 Jul '98

12 Jul '98

Perhaps we might have some success preventing smurfs from the most common sources, hacked machines on university dorm networks, by getting the university backbones to filter spoofs. Things like SUnet, FUnet, NYSERnet, etc, account for a large portion of universities used to smurf from, and it might be easier then trying to get each school to filter individually. I found the following two addresses for nysernet and funet but was unable to read or translate the Swedish on www.sunet.se. Gary Crane, Senior Director of Network Development, gcrane(a)nysernet.org Markus Sadeniemi, Director of FUNET, Markus.Sadeniemi(a)csc.fi

2 1

Re: SPAM, RE: Internic and there lame response
by Dean Robb 12 Jul '98

12 Jul '98

At 19:22 7/8/98 -0400, you wrote: On SPAM-L: >Here is Internic's lame response regarding some of the domains that they >seem to support spam houses.. Some of the domains are clearly spam houses.. >and I complained about one.. being registered to the same person and is >being used to spam the heck out of people.. here is there lame response >back.. seems Like internic is not gonna be of any help. InterNIC is NEVER any help. IMO, they are the single biggest blight on the Internet, mainly because they have so much power and choose to just sit back and collect $$ instead of use their power to do anything even remotely good. >The InterNIC, like all Internet users, is impacted by individuals >who send out "spam" (bulk e-mailing) on the network. However, >Network Solutions is responsible for the administration of the >name space and not for policing its content or use. True. >Removal of domain names belonging to users who send unsolicited >e-mail would make it harder, not easier, to track and filter >unsolicited e-mail from their domain. Several free software programs >allow users to filter incoming traffic from a specified domain. If >users sending unsolicited e-mail are forced to register new domain >names it also becomes harder for Internet users to track the origin >of the unsolicited e-mail. Straw man. "If we enforce the laws, the criminals will just get sneakier". > >Although we are concerned about the validity of information in the >WHOIS database, it is the responsibility of the domain holder to >maintain current information. Invalid phone numbers or non-working >e-mail addresses of contacts is not a valid reason for cancellation >of a domain name. Domain names are only deleted at the request of >the registrant or via our billing cycle if payment is not received. Except, of course, that the Registration Agreement that a domain registrant agrees to in order to get a domain says that the domain can be deleted for false information. IF InterNIC TRULY gave a damn about WhoIs, they'd enforce their contract. This is just a massive lie. Can someone with acess to a lawyer comfortable in Internet law PLEASE get an opinion on whether an "attractive nuisance" or other civil suit against InterNIC would work? > >Many Internet Service Providers (ISPs) have policies regarding bulk >emails. You may wish to contact the ISP of the user who sent you the >unsolicited e-mail. Incredibly two-faced response. How do you determine the user's ISP? Check WhoIs. But...OOOPPSS!...the information in WhoIs is phoney, and we don't do anything about that. Sorry, guess you're just screwed. Oh, but give us money! Our $16 million dollar quarterly profits just aren't enough. Why, we can't even afford to write a script that will only permit numbers in numberic fields of our registration templates! What do spammers and nails have in common? They're both intended for hammering. Dean Robb PC-Easy On-site computer services (757) 495-EASY [3279]

3 2

Re: SPAM, RE: Internic and there lame response
by Andrea Di Lecce 12 Jul '98

12 Jul '98

At 20:21 7/8/98 -0400, you wrote: >Incredibly two-faced response. How do you determine the user's ISP? Check >WhoIs. But...OOOPPSS!...the information in WhoIs is phoney, and we don't >do anything about that. Sorry, guess you're just screwed. There are many other ways to track a spammer. - Do nslookup on the IP that originated the spam (sometimes this takes a bit of detective work to find what IP actually originated the spam). - Traceroute to the originating IP. Email the ISP that is directly upstream. - Look in the Whois information for contact emails and nameservers - if these are for the upstream ISP, or some ISP other than the spammer, report it to them. - If they are advertising a web page, track the web page host, and their upstream, and report it to them. - If the spammer is stupid enough to use their real names, include their phone numbers and addresses in the complaint. Or call them up yourself and tell them what you think. Order pizzas with triple anchovies and pineapple, and no cheese. Order 50 pink flamingos on their front lawn, with a sign saying "Congratulations on your graduation from kindergarten !!" :) The above few lines *were* in jest. I probably would not include the sign. :) >What do spammers and nails have in common? They're both intended for >hammering. Amen. ************************************************** Andrea Di Lecce Rogers@Home Network Operations 1 Mount Pleasant Road, Toronto, M4Y 2Y5 **************************************************

2 1

Re: Process management
by Sean Donelan 11 Jul '98

11 Jul '98

>> >establish a out-of-band communication system [...] connected via >> >nationwide system which doesn't rely on IP, ATM, or SS7 >> >> I'm not sure where you'd find such a beast anymore. Maybe an SS7 and >> an Iridium system, side-by-side, would do the trick. > >HF radio, more likely. Those of you without roof-rights, you better >ask building management about getting same for the triband beam.... Actually I was thinking of a combination of 'order wires' with a combination of VSAT and in-band network conference bridges for backup. However several people of indicated that level of backup was too expensive. This problem isn't really unique to the Internet. I was looking at the backup communications network for SS7 providers and noticed a couple of major SS7 network providers don't give out their direct contact information even to other SS7 network operators anymore. They changed their listings in the emergency directory to general customer service numbers. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

ihnp4 and ihnss
by Jim Fleming 11 Jul '98

11 Jul '98

Re: Process management ---------------------------------------------------------------------------- ---- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ To: nanog(a)merit.edu Subject: Re: Process management From: Michael Dillon <michael(a)memra.com> Date: Fri, 10 Jul 1998 11:32:31 -0700 (PDT) Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <199807101554.LAA06003(a)nrk.com> Organization: Memra Communications Inc. Sender: owner-nanog(a)merit.edu ---------------------------------------------------------------------------- ---- On Fri, 10 Jul 1998, David Lesher wrote: > Let's see, we can put in 3 big stations: one in an old mill in > the Boston area, another in Arlington VA, and a third at ihnp4.. Explain, please. The first sounds like where DEC started out. Is the second MAE-East? And while I recognize ihnp4 as one of the central UUCP nodes I never knew what or where it was. -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael(a)memra.com Check the website for my Internet World articles - http://www.memra.com @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Michael, ihnp4 was a DEC VAX that was installed at AT&T Bell Laboratories at Indian Hill, in Naperville, Illinois. It was located in Building 6 on the 4th floor I think in E-aisle. Building 6 is the newer building behind the original collection of buildings at the corner of Naperville Rd. and Warrenville Rd. ihnp4 replaced ihnss. ihnss was one of the last large PDP 11/70s purchased at Indian Hill in Naperville in the late 1970s. I should know, I handled the SPA budget for it, and ordered it. It was a difficult decision not to buy a VAX at the time. We had to go with the proven PDP 11 because the VAX UNIX software was not stable enough when the orders were placed. We did research using ihnss. Phil Karn was new to Bell Labs and I encouraged him to take over ihnss when I left that location...I have not seen Phil since...when I returned to Indian Hill, ihnp4 was there...and Phil was gone...I assume that Phil somewhere along the line Phil convinced someone to convert it to a VAX...I suppose the increase in traffic was one of the reasons... I hope this helps to answer your questions about ihnp4 and also some of your questions about my association with AT&T... Jim Fleming Unir Corporation - http://www.unir.com

1 0

Re: network 32.100.0.0
by Sean Butler 10 Jul '98

10 Jul '98

>> Not sure what you are asking, but yes, the 32.100.0 /24 is a dial >> range IBM provides for Brazil... >many larger providers do not accept /24 in old A space. We send out the 32.0.0.0 /8 everywhere.... Sean, IBM Internet Support

1 0

Zebra homepage?
by Alex Bligh 10 Jul '98

10 Jul '98

In Kunihiro Ishiguro's NANOG presentation it mentions a Zebra homepage of http://zebra.digital-magic.co.jp/ which appears to be unknown to DNS (at least to mine) as do all obvious permutations. Zebra also seems absent from their web page. Anyone know of a newer Zebra resource? (web based preferably rather than mailing list - or a mailing list archive URL) -- Alex Bligh GX Networks (formerly Xara Networks)

2 1

Re: Simulating full BGP peers
by Darren_Bolding＠ec.enron.com 10 Jul '98

10 Jul '98

On 07/10/98 10:58:04 AM Ravi Puvvala wrote: >Take a look at http://www.qosnetics.com/QARbgp4.htm > And also, midnight networks ANVL product. www.midnight.com. Midnight, QosNetics and BGPsim are the only ones I know of except for some internal tools of various organizations.... Anyone know of other publicly available systems? --D -- -- Darren Bolding darren_bolding(a)ec.enron.com -- -- Enron Communications, inc. --

1 0

Re: T1 Circuit actual throughput 1290Kbp
by vaananen＠NASBPD01BS.ntc.nokia.com 10 Jul '98

10 Jul '98

>(!) The cell tax is about 10% -- the SAR expands user data from 48 >bytes to 53 bytes, plus an additional amount of overhead for internal >fragmentation on the final cell (AAL-5), plus overhead for whatever >encapsulation mode is being used. The cell tax is actually about 20%, based on the traces of the backbone IP traffic. Reason for this is the additional overhead imposed of partially filled cells. Fixwest 960926: total packets seen = 15315121, total payload bytes seen = 4276560002 ATM framing bytes = 5155881287 ATM efficiency = 82.95% ATM w/snap framing bytes = 5387212772 ATM w/snap efficiency = 79.38% Funet 970608: total packets seen = 6699991, total payload bytes seen = 2336213700 ATM framing bytes = 2783454053 ATM efficiency = 83.93% ATM w/snap framing bytes = 2919019891 ATM w/snap efficiency = 80.03% Pasi

2 1

Re: network 32.100.0.0
by Sean Butler 10 Jul '98

10 Jul '98

Not sure what you are asking, but yes, the 32.100.0 /24 is a dial range IBM provides for Brazil... Please take this off-line (off NANOG) and respond to me (or noc(a)ibm.net) directly with any questions you have. Thanks Sean Butler IBM Internet Support >Is that correct ? > DIGEX > MAE-East Looking Glass Results > > >Type escape sequence to abort. >Tracing the route to 32.100.0.116 > > 1 mae-east.ibm.net (192.41.177.110) 0 msec 4 msec 4 msec > 2 198.133.27.10 [AS 2685] 168 msec 252 msec 20 msec > 3 beth29-16-br2.md.us.ibm.net (165.87.29.18) [AS 2685] 0 msec 4 msec 4 >msec > 4 165.87.230.86 [AS 2685] 12 msec 8 msec 8 msec > 5 165.87.44.3 [AS 2685] 280 msec 156 msec 164 msec > 6 slip166-72-39-194.ri.br.ibm.net (166.72.39.194) [AS 2685] 156 msec 156 >msec 196 msec > 7 * > 32.100.0.116 [AS 2686] 1324 msec 444 msec > > >-- >Marcelo Manta >SAGA

2 1