Smurfing

Thu Feb 19 11:42:10 UTC 1998

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 at giganet.net>
> To: "Alex P. Rudnev" <alex at 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 at giganet.net>
> > > To: nanog at merit.edu
> > > Cc: Paul Ferguson <pferguso at 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 at 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)