Re: Network Operators and smurf
2. Routers/Gateways should be configured to drop all packets with invalid source addresses.
The problem is us. This isn't a research network run and maintained by the knowledgable. This is a business. We're selling a product, and if we expect it to operate as advertised, it's up to us to educate those we sell it to.
The problem isn't us. It's cicso, and Bay, and Ascend, and... everyone who won't put an anti-forging filter on their border routers so we _can_ turn it on. The first time someone co-sues cisco, it'll get fixed with 30 days.
Current recipe for anti-forging with Cisco hardware: o Pick up CEF code (11.1(17)CC, which doesn't yet (?) exist for all Cisco platforms, unfortunately) o Configure: ! ip cef switch ! or "ip cef distributed switch" for an RSP+VIP2 based box ! interface whatever ip verify unicast reverse-path ! This should (naturally) be implemented where routing is symmetric and where a "reverse-path check" (looking up the source address in the routing table to find the "expected" incoming interface and checking whether the packet did indeed enter through that interface) makes sense. If you have Ascend/Livingston or other dial-up equipment this check should probably be implemented in the closest up-stream router which has this capability, and definately not in a router which could take part in asymmetric traffic patterns. - Håvard
This should (naturally) be implemented where routing is symmetric and where a "reverse-path check" (looking up the source address in the routing table to find the "expected" incoming interface and checking whether the packet did indeed enter through that interface)
The big question is, what do you do if most of your traffic _is_ asymetrical? I mean, a more basic check could be, "Does the network that this packet was sourced from exist *at all*?", or "Do I have a route back to the source network through *any* interface?" That would cut down on a good amount of spoofing, like the idiots who spoof from 1.1.1.1 etc.
At 12:30 PM 4/25/98 -0400, Al Reuben wrote:
The big question is, what do you do if most of your traffic _is_ asymetrical? I mean, a more basic check could be, "Does the network that this packet was sourced from exist *at all*?", or "Do I have a route back to the source network through *any* interface?"
If your network is configured for shortest-exit routing, the peer routers that you would most likely use this on would have a very symmetrical view on traffic. This would appear to make this option look very enticing.. My major concern in using this is exactly how large of a CPU hit running this function costs. Does anyone have a feel on what this does to RSP2s & 4s on 75xx series routers with a decent amount of tables and traffic? Bri -- Brian Holt Network Engineer Nap.Net, L.L.C. (800)801-3920
Usially the low-end traffic is symmetrical. The problem is that CEF code and other anty-frauding realisations are appearing for the high-end routers, white they are nessesary for the low-end routers and useless for the core routers. For cisco, we need this future for 4500/4700/3640/2511 ASAP, 720x slightly, and don't need it for 75xx at all. On Sat, 25 Apr 1998, Al Reuben wrote:
Date: Sat, 25 Apr 1998 12:30:50 -0400 (EDT) From: Al Reuben <alex@nac.net> To: Havard.Eidnes@runit.sintef.no Cc: jra@scfn.thpl.lib.fl.us, nanog@merit.edu Subject: Re: Network Operators and smurf
This should (naturally) be implemented where routing is symmetric and where a "reverse-path check" (looking up the source address in the routing table to find the "expected" incoming interface and checking whether the packet did indeed enter through that interface)
The big question is, what do you do if most of your traffic _is_ asymetrical? I mean, a more basic check could be, "Does the network that this packet was sourced from exist *at all*?", or "Do I have a route back to the source network through *any* interface?"
That would cut down on a good amount of spoofing, like the idiots who spoof from 1.1.1.1 etc.
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)
Current recipe for anti-forging with Cisco hardware:
o Pick up CEF code (11.1(17)CC, which doesn't yet (?) exist for all Cisco platforms, unfortunately)
o Configure:
! ip cef switch ! or "ip cef distributed switch" for an RSP+VIP2 based box ! interface whatever ip verify unicast reverse-path !
I don't know what exact configs are vulnerable, but don't try this on a 7206 if you have a PA-8T with frame relay on it. I had CEF only on PA-2T3 ports and F0/0 on the controller card and yet all frame relay connections on multiple T1s on the PA-8T were trashed. cscdj87169 is not resolved yet.
participants (5)
-
Al Reuben -
Alex P. Rudnev -
barton＠cent.net -
Brian Holt -
Havard.Eidnes＠runit.sintef.no