Date: Thu, 19 Feb 1998 09:08:53 +0900 (JST)
From: Tatsuya Kawasaki <tatsuya@giganet.net>
To: "Alex P. Rudnev" <alex@Relcom.EU.net>
Subject: Re: Smurfing
thnx for the info and correcting what I said.
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@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)
Alex P. Rudnev