North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Smurfing
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 <[email protected]> > To: "Alex P. Rudnev" <[email protected]> > Subject: Re: Smurfing > > thnx for the info and correcting what I said. > > tatsuya > > > > > かわさき > > > = = = = = = > 電話 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 <[email protected]> > > > To: [email protected] > > > Cc: Paul Ferguson <[email protected]> > > > 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 > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > 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)
|