I didn't make it up to the microphone quick enough...
I have a question about the ip reverse-path verification. Obviously, it won't work very well in asymetric multi-homed environment. But, the usefullness could be there (even limitedly) if you could at least filter packets that have source address which does not exist in the routing table _at all_ (irregardless of ingress or egress interface). Is this something that could be implemented easily? -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex@nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP! We have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
On Tue, Jun 09, 1998 at 10:16:10AM -0400, Alex Rubenstein wrote: ==>I have a question about the ip reverse-path verification. Obviously, it ==>won't work very well in asymetric multi-homed environment. But, the ==>usefullness could be there (even limitedly) if you could at least filter ==>packets that have source address which does not exist in the routing table ==>_at all_ (irregardless of ingress or egress interface). ==> ==>Is this something that could be implemented easily? It would be another limited-functionality implementation -- it would work, but there are some cases under which it breaks -- consider the case where everything is summarized to default, or you only feed a default to edge devices that don't need the full table. Now, that wouldn't work in a smurf case because the source address *does* exist -- it's your target. It would help those cases where people are hit with, say, boink/bonk/etc. /cah
On Tue, Jun 09, 1998 at 10:16:10AM -0400, Alex Rubenstein wrote:
I have a question about the ip reverse-path verification. Obviously, it ip verify unicast reverse-path :)
won't work very well in asymetric multi-homed environment. But, the
Not on the core edges, but on customer edges it works well. The only problems we have are related to customers that have another provider and don't send us all their netblocks because of statics, etc.. (which can be easily fixed naturally).
usefullness could be there (even limitedly) if you could at least filter packets that have source address which does not exist in the routing table _at all_ (irregardless of ingress or egress interface).
This would be useful in a default-free network, but I'd be concerned with them deploying this in the lower end boxes that aren't default-free. It's hard to determine what is something to drop or not. What would be nice is a "ip drop private-blocks" or somesuch, but because many people build vpns, etc... with the lower end boxes also, as a vendor i'd be too concerned about that. - Jared
Jared Mauch wrote:
This would be useful in a default-free network, but I'd be concerned with them deploying this in the lower end boxes that aren't default-free. It's hard to determine what is something to drop or not. What would be nice is a
"ip drop private-blocks" or somesuch, but because many people build vpns, etc... with the lower end boxes also, as a vendor i'd be too concerned about that.
Of course, the existing RPF stuff only works on routers that support CEF, which rules out anything but the top of the line boxes. Alec -- +-----------------------------------+--------------------------------+ |Alec H. Peterson - ahp@hilander.com| Network Engineer | |http://www.hilander.com | Erols Internet - an RCN Company| +-----------------------------------+--------------------------------+
participants (5)
-
Alec H. Peterson -
Alex Rubenstein -
Craig A. Huegen -
Jared Mauch -
John Hawkinson