February 1998 - Test - lists.nanog.org

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

POP3 server3 on NT server 4 .0
by tien＠VNET.IBM.COM 14 Feb '98

14 Feb '98

Hi, Can someone suggest a few good POP3 mail servers on Microsoft NT server Version 4 ? Either freeware or commercial products are fine. Thanks a lot. Regards, Sung S. Tien tien(a)vnet.ibm.com

5 5

Performance probs / asymetric routing in the us
by Winfried Haug 14 Feb '98

14 Feb '98

Hello, we have sometimes heavy performance problems and we are now at the end of our knowledge :-) The facts: we have a 3 Mbit Part of the OC3 going from Frankfurt (ECRC/Ebone) to Sprint. We never had longer peaks, there is enough space in the line. Sometimes more than one MB/sec. Ping times are quite good, so this cant be the reason for our problems. Some ftp Downloads from US-Sites (cisco.com, sun.com etc...) are as fast as a ISDN line. (6-7 kb/sec :-)) othes have 60-80kb/sec... Several Traceroutes now have shown us, that almost all routes in the usa are asymetric: Just one example: Von nitrous.digex.net: Type escape sequence to abort. Tracing the route to anify.farside.net (195.110.11.2) 1 icm-mae-e-f0/0.icp.net (192.41.177.240) 4 msec 4 msec 4 msec 2 icm-bb1-dc-1-0-T3.icp.net (198.67.131.10) [AS 1800] 4 msec 4 msec 4 msec 3 icm-pen-1-1-0-T3.icp.net (198.67.131.18) [AS 1800] 8 msec 4 msec 4 msec 4 icm-pen-14-P0/0-OC3C.icp.net (198.67.142.70) [AS 1800] 8 msec 4 msec 4 msec 5 icm-pen-13-P1/0-OC3C.icp.net (198.67.142.97) [AS 1800] 8 msec 8 msec 4 msec 6 198.67.142.86 [AS 1800] 88 msec 88 msec 165.117.55.2 64 msec 7 NCP.Frankfurt2.ECRC.NET (192.121.158.110) [AS 1755] 92 msec NCP.Frankfurt2.ECRC.NET (192.121.158.110) [AS 1755] 88 msec NCP.Frankfurt2.ECRC.NET (192.121.158.110) [AS 1755] 92 msec 8 165.117.50.26 76 msec seicom-gw-FFM2.ecrc.net (195.27.83.90) [AS 1273] 112 msec seicom-gw-FFM2.ecrc.net (195.27.83.90) [AS 1273] 136 msec 9 US-gw.Frankfurt.seicom.NET (194.97.193.18) [AS 5549] 128 msec US-gw.Frankfurt.seicom.NET (194.97.193.18) [AS 5549] 168 msec US-gw.Frankfurt.seicom.NET (194.97.193.18) [AS 5549] 128 msec 10 Frankfurt1-s0-0.bw-bone.net (195.254.83.33) [AS 5549] 352 msec 140 msec 156 msec 11 Heidelberg1-s3-7.bw-bone.net (195.110.0.85) [AS 8254] 156 msec 156 msec 168 msec 12 portal.farside.net (195.110.7.34) [AS 8254] 196 msec 288 msec 336 msec 13 anify.farside.net (195.110.11.2) [AS 8254] 128 msec 148 msec 160 msec and the way back: traceroute to nitrous.digex.net (205.197.249.3), 30 hops max, 40 byte packets 1 195.110.11.1 (195.110.11.1) 3.218 ms 2.171 ms 2.065 ms 2 core1 (195.110.7.33) 7.054 ms 4.865 ms 5.615 ms 3 Frankfurt1-s0-0.bw-bone.net (195.110.0.86) 8.134 ms 7.691 ms 8.097 ms 4 195.254.83.34 (195.254.83.34) 8.886 ms 7.593 ms 7.070 ms 5 Ebone-gw.I-bone.NET (194.97.193.17) 14.484 ms 16.114 ms 16.668 ms 6 s1-0-r1-FFM2.ecrc.net (195.27.83.89) 38.792 ms 34.726 ms 65.364 ms 7 frankfurt-ebs2-h2-0-1.ebone.net (192.121.158.109) 59.266 ms 47.429 ms 39.759 ms 8 198.67.142.85 (198.67.142.85) 116.419 ms 107.364 ms 140.257 ms 9 sprint-nap.digex.net (192.157.69.42) 127.001 ms 133.519 ms 122.598 ms 10 phl2-core2-f4-0.atlas.digex.net (165.117.51.37) 276.222 ms 144.815 ms 134.420 ms 11 dca1-cpe2-h10-1-0.atlas.digex.net (165.117.51.33) 124.355 ms 127.911 ms 139.501 ms 12 dca1-cpe8-fe4-0.atlas.digex.net (165.117.224.2) 148.073 ms 144.636 ms 131.157 ms 13 nitrous.digex.net (205.197.249.3) 259.808 ms 170.213 ms 196.965 ms Currently we dont have a second path to the us, so it must have other reasons. The route object in the RIPE Datebase contains the correct AS and Maintainer. We dont have a advisory: AS690 1:1800 2:1239(147) 3:1239(218) 4:1239(144) which some ISPs have even it. Is this still necessary ? Does it make sense ? The Source IPs belong either to several /19 Blocks in 195.X.X.X or one /17 in 195.X.X.X or one /18 in 194.X.X.X.According to the filter- policies, theses ip-blocks are good enough :-=) Are there other sources for gernerating filter-lists on the core router in the us than the ripe datebase ? To avoid wrong results due to the server load: can anybody provide my a ftp-sute, which is connected very good (OC3 or more) and has no local load problems caused by too much user on the system... Winfried -- --- Winfried Haug | SEICOM.DE & SCHWABEN.DE | Tel. +49 7121 9770- 0 Laiblinsplatz 12 | Internet+ISDN access & consulting | Fax. +49 7121 9770-19 72793 Pfullingen | Access in STGT + RT + TUE + BB + LB | Rack +49 7127 989-X haug(a)schwaben.net| 150*ISDN (64kb/X.75) / 100 * K56flex | Rack +49 711 9675-X haug(a)seicom.net |SAP-OSS * FTP * TELNET * NETNEWS * IRC | Rack +49 7121 709-X * 10 MBit DE-CIX * 2 MBit INXS * 3 MBit ecrc/ebone * 2 Mbit Belwue * 2 Mbit WIN

1 0

Fiber cut in SJ 1:54 EST
by Richard Irving 14 Feb '98

14 Feb '98

There has been a fiber cut in SJ region affecting several carriers. The fiber carriers (WC) will be keeping everyone informed. Expect unusual flows. :( Darn these pesky natural disasters. ;)

1 0

A Nap is a Nap is a Nap
by Alex Rubenstein 14 Feb '98

14 Feb '98

Since I have seen a couple NAP annoucements lately, I figured I'd at least tell people about this one. It is called the NY-IIX, or the New York Internation Internet Exchange. It is located in neutral space, not operated or owned by and ISP or any Internet related company. It is operated by a co-lcoation known as Telehouse (http://www.telehouse.com) The switch itself is a Catalyst 5000, with switched 10 or switched 100 ethernet, or switched 100 FDDI. It has some peers in it already, and has the potential for being a very good XP; in the telehouse space alone are decent sized ISPs; us (nac.net) lightning.net, KDD Japan, Internet Initiative Japan, Mindspring, ANS, wisper, etc. (I am not saying they are all in the NAP, but they are in the co-lo, and have the potential to connect to the NAP). If you are interested, try Rick Mataka at 718.355.2500.

3 2

Re: Smurfing
by William Allen Simpson 14 Feb '98

14 Feb '98

Wow, I was glad to see that all these wonderful folks are reading the router requirements (RFC-1812, June 1995). Good, good. What I'd like to understand is how smurf attacks can work, even with directed broadcast on? Isn't there a requirement (RFC-1122) from ages past (October 1989) that ICMP not respond to broadcast or multicast [page 38 et seq]? What pressure is being put on host vendors? Which host vendors are the problem? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

2 2

Re: Smurfing
by Steve Hultquist 13 Feb '98

13 Feb '98

Don't these answers answer a different question? Isn't the question how to filter *outbound* attacks, not inbound ones? Filtering the inbound ones is pretty easy on a Bay or anything with filters (drop packets bound for the broadcast addresses). Filtering outbound is another story, especially with CIDR. I would like to set up my routers to make sure I'm protecting as much of the 'net as possible from attempts by my customers to do evil. However, it's not clear to me how to do that. Does "no ip directed-broadcast" somehow filter the *outbound* attacks or just the inbound ones? -- Steve Hultquist, Chief Technology Officer HSAnet providing high-speed Internet access Boulder, Colorado mailto:ssh@HSAnet.net +1.303.581.0800 http://www.HSAnet.net/

4 3

Re: Smurfing
by Chris A. Icide 13 Feb '98

13 Feb '98

At 02:52 PM 2/13/98 PST, Randy Bush wrote: > >why should this not have become the default mode for all vendor diustributed >router code? > was that meant to be "distrusted" code, or distributed? :) either way, we may want to do a quick list of such commands, including the following: ip classless ip subnet-zero what ones did I miss? ************************************************************** Chris A. Icide voice: +1-650-482-2840 Chief Technology Officer fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "Tommorrow's Performance Today." - Notice: NVRAM invalid, possibly due to write erase. Press RETURN to get started! - PGP Keys located at pgpkeys.mit.edu **************************************************************

1 0