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
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
==>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
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