Re: Smurfing

["Alex P. Rudnev" <alex () Relcom EU net>]

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 () giganet net>
> To: nanog () merit edu
> Cc: Paul Ferguson <pferguso () 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 () 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)