On Thu, Sep 19, 2002 at 11:14:01AM -0700, Crist J. Clark wrote: > On input packets, it'd be painful and not really practical. On output > packets, it shouldn't be _too_ bad since the routing information would > be available. > > I'm not quite sure I understand why it would be needed. If there isn't > a route to send a packet out of an interface, it won't go out of the > interface. Under what conditions would you see yourself blocking > packets? Is this really an ackbassward way to filter routes from > routing daemons?
Sounds like he wants an implementation of unicast reverse path forwarding (uRPF) loose-mode to prevent source address spoofing of non-announced space. uRPF is simple, you do a 2nd routing lookup on the src address to check for a valid return route, either a) with a nexthop to the interface on which the packet was received, for filtering customers, or b) with a nexthop to any interface, for inbound on network borders. Strict-mode is only useful for devices which route, but loose-mode could potentially be used to reduce the impact of random source DoS attacks (sounds like something linux would do :P). Unfortunately, the performance impact of doing radix tree lookups for a full routing table to filter this way would probably be worse than not filtering at all. While any device which calls itself a modern router SHOULD have this functionality, I think there are more important things to fix first. :) -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
