February 1998 - Test - lists.nanog.org

Re: Broken domain statistics...
by dlr＠bungi.com 17 Feb '98

17 Feb '98

[In the message entitled "Re: Broken domain statistics..." on Feb 13, 2:24, Jon Lewis writes:] > > That brings up another question. What can/should be done with such > "tainted" IP space? Who in their right mind would want space previously > used by Cyberpromo? It's almost as if they destroyed the IP space they > used. > It's an interesting question. I had the first dealing with it a couple of days ago. A site called me, and wanted off the RBL. Turned out it was one of the sites that hosted a nameserver for a few days for Cyberpromo. After the standard set of questions, I removed them - but I know that they are going to have a whole heap of trouble with the thousands of other sites that were blocking Cyberpromo. Without a central registry, unblocking "bad" addresses is going to be a huge job. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

4 4

Notes from the Februray 1998 meeting
by sob＠academ.com 17 Feb '98

17 Feb '98

They are now starting to appear at this URL http://www.academ.com/nanog/feb1998 They are not in the index as yet. Also, I will be asking for slides from those talks I don't have available to me. If you know you have not sent them to me, please contact me. Otherwise, you will hear from me via private email. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: Fiber cut in SJ 1:54 EST
by Sean Donelan 16 Feb '98

16 Feb '98

>They will? How many know about the cut in Atlanta Sunday? 8-12 hrs? I >don't know exactly. Do they (WorldCom) have a maillist for trouble and >scheduled maintenance or a status page? And what happened to their website? >Their dns entry is gone. The mailing list outage(a)dal.net has some multi-provider outage information. Although, like most mailing lists, the quality of information depends on contributors to the list. www.wcom.com is the parent corporation web site. Whether 'they' have a mailing list for trouble or scheduled maintenance is a very different question than do 'they' bother posting anything to it. During some outages it takes MFS's service center 40 minutes to answer the phone. WCOM is taking up to 15 minutes to answer the phone. "Answer" means reach someone/something that can give accurate information and open a trouble ticket, as opposed to the "Your call is very important, please wait...." recording. Misc. California: Too many to itemize. Unstable ground has affected several facilities-based carriers. AT&T, MCI, Pacbell, Worldcom, etc have had one or more circuit failures in the last week. Although I believe most of the MAE-West issues have involved human activities, some with prior notice, some without notice. Buckhead, GA: Worldom 28 OC-12 circuits out of service, 8:06am-1:02pm on Sunday. reason: fiber cut ?human/nature? And to show I'm not just beating up on Worldcom... Here's one for AT&T's latest aquisition, TCG/Teleport. St. Louis, MO: TCG/AT&T takes their SONET ring out of service 00:56am-3:18am Sunday. reason: scheduled maintenance, prior customer notice: no. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

ISP (dialup) for SE Asia?
by Dean Anderson 16 Feb '98

16 Feb '98

Can anyone recommend an ISP(s) which can do local dialup in SE Asia, specifically Taiwan, Singapore, and Korea? Japan is already done, but we don't have local, in-country contacts for these other places. Thanks in advance, --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

5 4

Re: RA/RV Feeds from RBN
by Sean M. Doran 16 Feb '98

16 Feb '98

brandon(a)rd.bbc.co.uk (BrandonButterworth) writes: > If MBONE is to be a serious contender the ISPs must > deliver it, then us content providers that are wasting > tons of net bandwith could become nicer netizens and > wouldn't use the unicast products that end users are > asking for. Of course the ISPs may not take as much > money off us as we wouldn't need quite so much bandwidth > (perhaps there's a reason there?) The real problem is that IPv4 Multicast scales badly with the number of groups, and Multicast routing is difficult. If you doubt any of this, kindly review the recent Dave Meyer presentations at any of your favourite conferences. Content multicast is *wonderful* news for any ISP that overbooks its backbone capacity: the amount of overbooking possible increases with the volume of highly-popular scheduled content. That is, if you have lots of replication happening in multicast routers (presumably because your customers have things attached to them who want the same content at the same time), then you can fill your customer links with stuff that has less impact on your relatively large backbone pipes. InternetMCI is among a number of ISPs who have worked on eliminating redundant copies of multicast traffic crossing their backbones by deploying MBONE infrastructure. This is not the same as deploying a multicast infrastructure, however that is a very different rant. So, frankly, your suggestion that ISPs make less money off you when there is lots of well-laid-out distribution trees carrying lots of content to lots of places is simply wrong. The problem is mostly that people are busy making unicast mostly work and are finding that sufficiently difficult that making multicast work better than it does now just does not get attention, particularly since multicast routing is hard and multicast routing code is buggy at least in part due to that. The lack of perceived utility for multicast also has an effect on the other side of a cost-benefit analysis that does not favour rapid deployment. Sean.

2 1

Smurfing
by Alex Rubenstein 16 Feb '98

16 Feb '98

One of my customers is being smurfed right now. Filling a 10 Meg to UU Net. It is wonderful to know that everyone has 'no ip directed-broadcast'. It's *SO* easy to do!

10 9

Re: Fiber cut in SJ 1:54 EST
by Matt Sommer 16 Feb '98

16 Feb '98

-----Original Message----- From: Richard Irving <rirving(a)onecall.net> Date: Saturday, February 14, 1998 4:56 PM Subject: Fiber cut in SJ 1:54 EST >There has been a fiber cut in SJ region affecting several >carriers. The fiber carriers (WC) will be keeping everyone >informed. Expect unusual flows. > > :( They will? How many know about the cut in Atlanta Sunday? 8-12 hrs? I don't know exactly. Do they (WorldCom) have a maillist for trouble and scheduled maintenance or a status page? And what happened to their website? Their dns entry is gone. I subscribed to weather-talk(a)internetweather.com but there's not much posting there. Any other sites or lists for outages? Matt Sommer Sysadmin

2 1

whois
by Bill Becker 16 Feb '98

16 Feb '98

Have i Missed Something or is whois broke today? --------------------------------------------------------------------- biteme:~$ whois 38 [rs.internic.net] No match for "38". The InterNIC Registration Services Host contains ONLY non-military Domains and POC's. Other associated whois servers: American Registry for Internet Numbers whois server - whois.arin.net European IP Address Allocations whois server - whois.ripe.net US Military whois server - whois.nic.mil ---------------------------------------------------------------------- Oh well.

6 7

Re: Smurfing
by William Allen Simpson 16 Feb '98

16 Feb '98

Thanks for the excellent reply, although you forgot to mention that every other ICMP message, including error messages, timestamps, and such, MUST discard broadcast/multicast. Echo is the _only_ MAY be discarded. As the discussion notes, there was some controversy. I vaguely remember the discussion at the time. But _all_ the stacks that I've ever worked on follow the MAY and _do_ the discard. Maybe I should join a *nix group. We need to put pressure on vendors (especially router vendors and large commercial host vendors) to _discard_ by default. I am unaware of any troubleshooting value. After all, should you want to scan for hosts, use SNMP. Or increment your ping address. Lots of simple harmless ways to do the same thing. Especially since you need to know the (now variable) local mask to effectively use a directed broadcast anyway. Directed broadcast was a kludge in the first place. Maybe it's time to deprecate it entirely. > From: "Craig A. Huegen" <chuegen(a)quadrunner.com> > Most stack implementors have chosen to respond to it because of its > troubleshooting value; then again, the date of the RFC shows why many > folks would tend to believe the threat of the attack wouldn't be very > large. > WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

2 1

Re: Smurfing
by Havard.Eidnes＠runit.sintef.no 16 Feb '98

16 Feb '98

Hi, 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. It's conceivable that "a significant portion of all" would do as well, but the magnitude of this problem boggles the mind. First of all, we'd need to distribute the appropriate amount of clue to all the corners of the net where this needs to happen. Maybe, just maybe, we'll get there sometime (I'm an optimist!). o Making sure source IP address spoofing isn't as easily done as it is now. Also an easy one, right? ;-) Anyone have any idea where most of the attacks originate: dial-up ports or from folks more directly connected to the net? (I'd bet on a happy mix ;-) Equipment providers can offer some help here in offering an effective and efficient knob which can do the equivalent of "RPF"ing on unicast traffic (if you don't have a route back to the source and the route doesn't point to the incoming interface for the packet, drop it on the floor). Obviously, this assumes symmetric traffic patterns, which are typical at the edges of the network but not quite so typical in our/your modern backbone networks. 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. o Lastly, I think that better tools are needed to track this sort of attacks back to their source (?). I'm not saying these battles should not be fought; far from it, but it's probably going to take a while before any of these can have any significant effect on the problem. - Håvard

9 9