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!).
On Feb 13, 2:52pm, Randy Bush wrote: * *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.
Prehaps RFC1812 *should* be updated to reflect that this is destructive behavior. Having said that, this is work whch should be suggested to the IETF -- the NANOG participants, being operations focused, are in a very good position to make noise on this front. - paul
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>.
Prehaps RFC1812 *should* be updated to reflect that this is destructive behavior.
Having said that, this is work whch should be suggested to the IETF -- the NANOG participants, being operations focused, are in a very good position to make noise on this front.
I thought I was doing so, only to be informed I was a prevert. :-) randy
On Mon, Feb 16, 1998 at 12:44:00AM -0800, Randy Bush wrote:
Having said that, this is work whch should be suggested to the IETF -- the NANOG participants, being operations focused, are in a very good position to make noise on this front.
I thought I was doing so, only to be informed I was a prevert. :-)
You are, Randy, but don't let it worry you... Cheers, -- jr 'You're in good company' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
Subject: Re: Smurfing
Prehaps RFC1812 *should* be updated to reflect that this is destructive behavior. 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.
Having said that, this is work whch should be suggested to the IETF -- the NANOG participants, being operations focused, are in a very good position to make noise on this front.
- paul
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>.
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)
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.
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
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
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)
participants (7)
-
Alex P. Rudnev -
Bradley Reynolds -
Jay R. Ashworth -
Kelly J. Cooper -
Paul Ferguson -
Randy Bush -
Tatsuya Kawasaki