- Test - lists.nanog.org

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

17 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 17 Feb '98

17 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 17 Feb '98

17 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

NSI Bulletin 098-003 | ARIN Announcement
by Chuck Gomes 16 Feb '98

16 Feb '98

Effective immediately, information about networks, autonomous system numbers, and inverse addressing records will only be available from ARIN's Whois servers via telnet at WHOIS.ARIN.NET. The Whois database managed for the InterNIC by Network Solutions will no longer be the authoritative source for IP numbers, autonomous system numbers and inverse addressing records. On December 22, 1997 the American Registry for Internet Numbers (ARIN) assumed responsibility for IP address allocation and network registration functions previously performed by the InterNIC. As part of the process to separate ARIN from the InterNIC, services related to IP address allocations, autonomous system numbers and inverse addressing are no longer available from InterNIC Registration Services. Changes and updates to these records need to be made by contacting ARIN via e-mail at hostmaster(a)arin.net. NOTE: the WHOIS database maintained by InterNIC Registration Services (Network Solutions, Inc.) will remain as the authoritative source for .COM, .NET, .ORG and .EDU domain name information. In some cases, such as updates to host records, it may be necessary to file an update request with the InterNIC and also ARIN. For example the IP address of a host record may need to be updated with InterNIC Registration Services and a request may need to be made to update the inverse addressing records maintained by ARIN. Information about Network Solutions, Inc is available at http://www.netsol.com. Information about ARIN is available at http://www.arin.net. _____________________________________ Chuck Gomes Director of Customer Programs Network Solutions, Inc.

1 0

Re: Smurfing
by Sean M. Doran 16 Feb '98

16 Feb '98

| > 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! You probably can't, however the point Håvard was making is that if you deny people the opportunity to spoof the origin of their packets, you deny people the ability to engage in long-term denials-of-service of this nature, and you increase the liklihood of catching the individual perpetrator. These two things will tend to reduce the number of Smurf and other attacks. | > 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! Håvard mentioned work going on to do RPF checking. A feature that looked for "out of profile" RPF-failed traffic but that did not drop RPF-failed traffic in general would be a useful debugging tool. Out-of-profile traffic ought to include any large amount of traffic over a sustained period. More cleverly, if the traffic is not TCP traffic or if it is TCP traffic but does not appear to react to induced early packet loss (i.e., you drop a packet deliberately and wait for the sender to react with a retransmit and a decrease in sending bandwidth) and it fails the RPF test, ring alarm bells and optionally drop the traffic altogether. RPF, btw, is "reverse path forwarding", which comes from the wonderful world of multicast lingo. Essentially when you do any type of flooding you ant to make sure you don't forward the flooded traffic back in the direction from which you heard it in the first place. In the world of unicast it is a short-hand way of saying that you check to make sure that a particular packet came from the direction in which you route traffic destined for that packet's source address. Sean.

1 0

Re: Smurfing
by shields＠crosslink.net 15 Feb '98

15 Feb '98

In article <Pine.QUAD.3.96.980213225740.16562C-100000(a)quad.quadrunner.com>, "Craig A. Huegen" <chuegen(a)quadrunner.com> wrote: > "ipfw" can be used from Linux to block broadcast echos, a la: Or the kernel can be trivially patched. http://www.geek-girl.com/bugtraq/1997_3/0158.html -- Shields, CrossLink.

1 0