February 1998 - Test - lists.nanog.org

Re: Smurfing
by Alex P. Rudnev 19 Feb '98

19 Feb '98

To summarise all answers I'h got to my question: - there is RFC recommendations about implementation for this filtering; - CISCO have such filtering in their new forwarding scheme; - there is (already) experimental IOS images supported such filtering; - for now, this filtering is not possible (in CISCO) at the access servers, but at the core routers only. This means something like _CISCO know about this problem and work around it, but there is technical problems in implementing this for the low-end routers_ - this is as I understood all answers (not only from CISCO). Thanks to all who have answered. Aleksei. On Thu, 19 Feb 1998, Tatsuya Kawasaki wrote: > Date: Thu, 19 Feb 1998 09:08:53 +0900 (JST) > From: Tatsuya Kawasaki <tatsuya(a)giganet.net> > To: "Alex P. Rudnev" <alex(a)Relcom.EU.net> > Subject: Re: Smurfing > > thnx for the info and correcting what I said. > > tatsuya > > > > > $B$+$o$5$-(B > > > = = = = = = > $BEEOC(B 03-3239-0607 fax 03-3239-2609 > business network telecom > http://www.giganet.net > > On Wed, 18 Feb 1998, Alex P. Rudnev wrote: > > > CISCO can filter by any SRC address. The only question I am asking every > > time is _would CISCO can do it by default and by direct routing tables?_. > > THis means something like: > > > > interface xxx > > ip src-filtering selfpaths > > > > and that means _packet from interface xxx should be received ONLY if SRC > > address should be routed to the same interface_ (if you have > > 193.124.25.0/24 network statically routed to your interface, and address > > 194.58.1.1/30 on this interface, you can only send packets with the SRC > > addresses 193.124.25.0/24 and 194.58.1.1/30. > > > > And it's important to understand _IT SHOULD BE DEFAULT BEHAVIOUR ON THE > > ACCESS SERVERS_ (may be controlled by some extra comman), so that any > > (even dumb) network administrators could use this property withouth extra > > configuration. > > > > ------------------- > > > > > > > > > > On Wed, 18 Feb 1998, Tatsuya Kawasaki wrote: > > > > > Date: Wed, 18 Feb 1998 10:36:32 +0900 (JST) > > > From: Tatsuya Kawasaki <tatsuya(a)giganet.net> > > > To: nanog(a)merit.edu > > > Cc: Paul Ferguson <pferguso(a)cisco.com> > > > Subject: Re: Smurfing > > > > > > paul, > > > it sounds a good idea but is it possible? > > > I don't think cisco can filter by wrong SRC address bases. > > > ^^^^^ > > > you still can use still use any ip on the same segment. > > > (Big deal, huh? :-) ) > > > Furthermore, it will cause some problem for Mobile IP stuff, > > > if I remember correctly. > > > > > > regards, > > > > > > tatsuya > > > > > > > > > On Tue, 17 Feb 1998, Bradley Reynolds wrote: > > > > > > > > See RFC2267. > > > > > > > > > > - paul > > > > > > > > > > > > > > > > Good news. > > > > > > > > > > > > One more question (just is there is someone from the CISCO) - what's > > > > > > about source-address filtering at default for the access servers/routers? > > > > > > Note all this problems (SMURF, DENIAL-ATTACK, DNS-FRAUDING, etc etc) can > > > > > > be 100% blocked if ISP would not allow it's customers to send IP packets > > > > > > with the wrong SRC address. If not, they (hackers) should found new, new > > > > > > and new tricks to fraud any IP network. > > > > > > > > > > > > > > > You can apply the RPF idiom from multicast to block unicast > > > > flooding. This would instantly solve the problem, though I am > > > > not sure what overhead the path evaluation would incur. > > > > > > > > BR > > > > > > > > brad(a)iagnet.net > > > > > > > > > > > > > > > > > > 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) > > > > > > 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)

1 0

Re: SMTP spoofing ?
by sully＠mail.usinternet.com 19 Feb '98

19 Feb '98

Yes, NAT on cisco's. Tim Sullivan Network Hobbyist At 11:52 AM 2/19/98 -0500, you wrote: >Are there any routers currently available that can do port 25 spoofing for >dialup users? That is, when the user attempts to connect to port 25 >anywhere, he in fact connects to port 25 on your own SMTP server instead. > >In case it's not obvious, it's for spam management. > >Regards, >John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", >Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner >Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47 > > ------------------------------------------------------------------ Tim Sullivan Senior Technical Administrator/Support/Network Consultant http://www.usinternet.com US Internet Corp - Full Service Internet Provider "Get your Net's Worth" (tm) (612) 222-4638 ------------------------------------------------------------------

1 0

Internic WHOIS down?
by chris＠unix.org 18 Feb '98

18 Feb '98

The whois database has been up and down (mainly down when I've tried to use it) for about two days now .. anyone know why/when it'll be fixed? -- Chris Portman ================================================= chris(a)unix.org Senior Systems Operations and Security PSI Canada Ltd (Formerly ISTAR) (613) 788-7767 Ottawa, ON, CA

3 2

[non-op] Philippines language, culture stuff
by miguel a.l. paraz 18 Feb '98

18 Feb '98

In case you didn't know, practically everyone in Manila (down to the bus driver) can speak basic English. ISP personnel will speak very good English, except for the usual context/grammar changes. Thank you America for 1900-1946, but if you would like to help the APRICOT host country somehow and have a debt of gratitude, see <http://www.newprint.com/balangiga/balabann>, this is important to me. Thanks. ---m

1 0

[non-op] APRICOT, Manila web cam and other helpful info
by miguel a.l. paraz 18 Feb '98

18 Feb '98

Hi, If you really must *see* your colleague in Manila, we have a Color Connectix here hooked up to a Linux box. I'm currently setting it up at http://www.ph.apricot.net. I'm using the non-realtime cqcam for Red Hat/X and can do about a max of 5 pics per minute (currently driving it at 1/minute). Sorry, no sound cards available. If you want real videoconf, be prepared to pay a princely sum (US$2/minute) for ISDN Manila-US, or, help me configure something that runs on Win95/Linux/FreeBSD. For DIYers, get in touch with me to reserve some bandwidth (manually) on this line: ~ 300-500 copper circuit meters Shangri-La------------PLDT PHiX------Intelsat---------Teleglobe Hotel Manila 2 * 2 Mb/s 4 Mb/s Lands at Vancouver, BC <10 ms >600ms Transit: Sprint/MCI/UU/? | | 512 Kb/s, around 1 km away, <20ms | IPHIL.NET (AS4743, but static at the moment) mostly 203.176.0.0/18 | | 3 MB/s aggregate MCI PLDT == Philippine Long Distance Telephone PHiX == Yup, the telcos run the IXs here too I'm doing some tests here with persistent HTTP/1.1 (probably with Justin Newton if he comes by) and how it gives us a perceived 2x - 3x speedup (will see if we could roll the numbers later) I'm talking on this in a while (as well as a new way to look at the whole caching business, unless someone douses cold water on me. Basically you want your 1000 customers to have a 20 MB cache each rather than you maintain a 20 GB cache...) If you want the whole thing with pictures, we could work up something (ask your colleague to feed the IPhil Comms network engineering and consulting groups, any pizza appreciated) You can also check with me on the location of any particular person and his state of connectivity, if I know him... APRICOT won't make the reg database public, obviously. ISP connections are around US$1/hour (I can arrange one for you) but they usually need a ~US$30 non-refundable fee if it's more than 5/10 hours. GRIC/IPass have good local partners too. Cheers, ---m -- IPhil Communications Technology Group http://www.iphil.net +63-2-750-2288

1 0

Re: Smurfing
by Kelly J. Cooper 18 Feb '98

18 Feb '98

On Feb 13, 2:52pm, Randy Bush wrote: > Subject: Re: Smurfing *> 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!). * *why should this not have become the default mode for all vendor diustributed *router code? * *randy >-- End of excerpt from Randy Bush Perhaps because RFC 1812, "Requirements for IP Version 4 Routers" (which I believe is still current) needs to be updated/made obsolete? Excerpted from section 5.3.5: A router MAY have an option to disable receiving network-prefix- directed broadcasts on an interface and MUST have an option to disable forwarding network-prefix-directed broadcasts. These options MUST default to permit receiving and forwarding network-prefix- directed broadcasts. Or perhaps because the folks on this list haven't made it clear enough to their vendors that the default should be "off" <hint>. Kelly J.

7 9

Re: RA/RV Feeds from RBN
by Vadim Antonov 17 Feb '98

17 Feb '98

Tony Li wrote: > Ok, it's not clear to me that a niche application implies that the amount > of traffic is insignificant. If UUnet decides to deliver live real-time > CNN to all desktops in all of their customers, that IMHO might be > significant. Hmmm... Isn't that in the definition of "niche"? There always were very high-bandwidth applications (like access to supercomputers). If there's enough money in those applications, they'd merit building of separate networks. So far i see equipment, software and operational costs of multicasting by far exceeding any possible gain, for public carriers. | PS I do not see how isolated network violates "all assumptions". Well, my primary assumption was that we're talking about global Inetrnet, not about relatively small private networks. > For example, you assumed (implicitly) that arbitrary systems could become > mcast sources. Clearly the UUnet model does not allow this. This makes > the problem tractable. If we don't allow arbitrary systems to be sources, then we already have the network designed for that kind of traffic - already deployed and accessible to many more customers than Internet. It's a lot cheaper to fly a bird up there than to drag T-1 to every house. BTW, how do they fix security problem with mcast packets having forged addresses? | And i fail to see why the same functionality (and a lot more) | couldn't be implemented in application-level host-based | caches/mcast servers. There's no particular reason to drag these | functions into core gateways. > Once again, if the traffic volume is significant, there would be a > significant bandwidth savings. Doing multicasting in host software allows _bigger_ bandwidth savings - because things like rate conversion and retaining of data for delayed transmission can be done closer to clients. Actually, CNN "on TV" is the perfect example - they run the same segments over and over again. Of course, to do that with significant traffic volumes one would need to have real big computers in POPs. Sounds like something somebody's building. --vadim

1 0

Re: RA/RV Feeds from RBN
by Tony Li 17 Feb '98

17 Feb '98

Vadim, I sympathize with all of your cogent comments when applied to multicasting in the large. However, multicasting in the small, as practiced by certain ISPs seems to violate all of your assumptions and thus violates your conclusions. A specific example is UUcast. Comments? Tony

3 3

Broken Pipe errors with dialup users
by Mark Tripod 17 Feb '98

17 Feb '98

We are experiencing an intermittant problem where dial-up users that access our customers web servers through our Sprint NAP connection get "broken pipe" errors. This problem seems to appear with a greater frequency with users that use Apple Macintoshs with MacTCP, although Win95 users have also complained of the same problem. With the Win95 users they can change their local MTU setting to 1500 and the problem disappears. We are connected to the Sprint NAP via a full duplex Fddi PA on a Cisco 7505. Anyone encountered this type of problem before? Any thoughts would be greatly appreciated. Off I go to dig into the packets and start testing :) Thanks, Mark Tripod Senior Backbone Engineer Exodus Communications

1 0

of course you're invited...
by rlife＠daltek.net 17 Feb '98

17 Feb '98

The Truth? This really is a once in a lifetime opportunity. take a look at how you can be on the FOUNDERS LEVEL of a company that is destined to be HUGE! The pre-launch just started! The products are awesome and guaranteed! The comp-plan is insane! The Bonuses are enourmous! SPILLOVER GALORE! and on and on! http://209.84.113.45/rightlife/index.htm http://209.84.113.45/rightlife/products.htm http://209.84.113.45/rightlife/compplan.htm Trust me, don't miss out. If these servers are busy due to the enourmous rush for positioning go to this one... http://world-space.ids.on.ca/users/rightlife/ ************************************** we honor all remove requests. reply with "remove" in subject. **************************************

1 0