It doesn't seem to be working for me. What version of IOS does this new feature show up in? Why hasn't it been mentioned before? Or is this not similar enough to be usable to block smurf and other forgery? Danny McPherson writes...
Cisoc already has a feature similar to this, "ip verify unicast reverse-path".
-danny
Danny McPherson writes...
ingress filtering .. that's a novel idea :-)
"smart" ingress filtering, as opposed to hard coded filtering, which is already done a lot. It would come at some costs, as every packet would have to have 2 routing lookups done for it, one of which must return or compare against all routes, not just the best route.
-- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --
it's a CC feature in the 11.1 train, it's been mentioned before, and should be applied per-interface. --- Tung-Hui Hu (HH26) 734.996.4911 http://arcfour.com : It doesn't seem to be working for me. What version of IOS does this new : feature show up in? Why hasn't it been mentioned before? Or is this not : similar enough to be usable to block smurf and other forgery? : Danny McPherson writes... : > Cisoc already has a feature similar to this, "ip verify unicast : > reverse-path".
The reverse-path check is best applied at the CPE router or the access router, not in your backbone. If you end up with asymmetric routing (a common occurrence these days) there may not be a reverse path for that packet you just got from your neighbor and (plop) a valid packet (or thousand) get dropped when they should not have been. I also don't think it's such a hot idea to be universally filtering "n.n.n.255" without explicit prior knowledge of the netmask of the network involved. Apple Computer, for example, used a 14 bit subnet mask on net 17 and we used every address in the 10-bit host space that was available to use with that scheme, including the three where the last octet is 255. Make certain that all your customers know that you're doing this - otherwise they may be puzzling over why connectivity works from every address in their net number, except for one or two... Erik <fair@clock.org>
The reverse-path check is best applied at the CPE router or the access router, not in your backbone. If you end up with asymmetric routing (a common occurrence these days) there may not be a reverse path for that packet you just got from your neighbor and (plop) a valid packet (or thousand) get dropped when they should not have been.
The assymetric routing I've seen is generally outside of our network, e.g. BGP inconsistency where our traffic to www.otherisp.com goes one way and their traffic to us comes in another. Even then we do have BOTH routes to them most of the time, using only a preferred one. But within our own network, I strive to make sure there are no asymmetric routes anywhere.
I also don't think it's such a hot idea to be universally filtering "n.n.n.255" without explicit prior knowledge of the netmask of the network involved. Apple Computer, for example, used a 14 bit subnet mask on net 17 and we used every address in the 10-bit host space that was available to use with that scheme, including the three where the last octet is 255. Make certain that all your customers know that you're doing this - otherwise they may be puzzling over why connectivity works from every address in their net number, except for one or two...
We filter n.n.n.255 on incoming only, not on outgoing. That's safe for us to do because none of our subnets are larger than /24. We have only one customer with more than a /24 and their network is all subnetted with lots of smaller than /26 anyway. All space allocations to customers go through me and I will be checking out anything larger than /24 for certain reasons other than n.n.n.255. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --
On Wed, Oct 21, 1998 at 12:40:14PM -0700, Erik E. Fair wrote:
I also don't think it's such a hot idea to be universally filtering "n.n.n.255" without explicit prior knowledge of the netmask of the network involved. Apple Computer, for example, used a 14 bit subnet mask on net 17 and we used every address in the 10-bit host space that was available to use with that scheme, including the three where the last octet is 255. Make certain that all your customers know that you're doing this - otherwise they may be puzzling over why connectivity works from every address in their net number, except for one or two...
I was one of the participants in the last war on this topic here, and I feel the need to point out that I read him as saying he _ingress_ filtered 255, not egress filtered it. He can be expected to know if his own internal network has any non broadcast .255's, I'd think. (He wasn't a reseller, was he? :-}) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Buy copies of The New Hackers Dictionary. The Suncoast Freenet Give them to all your friends. Tampa Bay, Florida http://www.ccil.org/jargon/ +1 813 790 7592
Check the whitepaper at: http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip It's got some reverse-path and ingress/egress filtering write-ups. Barry
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Hui-Hui Hu Sent: Thursday, October 22, 1998 2:34 AM To: Phil Howard Cc: nanog@merit.edu Subject: Re: Actions to quiet the Smurf amplifiers?
it's a CC feature in the 11.1 train, it's been mentioned before, and should be applied per-interface.
--- Tung-Hui Hu (HH26) 734.996.4911 http://arcfour.com
: It doesn't seem to be working for me. What version of IOS does this new : feature show up in? Why hasn't it been mentioned before? Or is this not : similar enough to be usable to block smurf and other forgery?
: Danny McPherson writes...
: > Cisoc already has a feature similar to this, "ip verify unicast : > reverse-path".
participants (5)
-
Barry Raveendran Greene -
Erik E. Fair -
Hui-Hui Hu -
Jay R. Ashworth -
Phil Howard