It's called unicast-rpf . . . there are special considerations when you're multihomed, see http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf. Eric Oosting wrote:
Has there been any work done, or is it even a good idea to implement something kinda like the RPF check in Multicast, but for unicast, that could be used on interfaces at AS boundaries.
As each packet is accepted on an interface, the source address of the packet could be checked as being in a prefix that is advertised by the bgp peer that sent you the packet. This could be done by the router, with only a config statement on the interface to turn it on. The idea being that if another AS sends you a packet with a particular source address, they better have a way back to the source. Packets that did not meet this criteria could either be denied or logged. (If dumping them is too harsh, atleast logging them could help track attacks)
This could be useful at peering boundaries for both parties, where full views are not exchanged. This could also be used by ISPs on customer interfaces, as long as all potential source addresses are advertised over the bgp session, which is not necessarily the case with customer sessions. (Note: Most peering agreements require the same routes advertised at all points ... not the case with customers)
I know that this could be automated by creating access lists from bgp advertisements using auto-magic scripts, but it wouldn't be in real time, making it useless IMHO. It would also make the configs huge. (well, huger, if that were a word.)
There are the obvious hardware considerations... Can todays hardware support access lists of this size at line rate? Will they for be able to for long?
Under what circumstances would the assumption (that an AS should always advertise a route to the source address of packets it transmits) not be a good one?
Of course this could be turned around and the capability made to deny or log packets with a source address that you are not advertising a route to.
Thoughts?
Eric
Eric Oosting eric@netrail.net office:404.739.4385 Sr. Network Engineer Network Eng and Operations NetRail, Inc
On 23 Jun 2001, Paul Vixie wrote:
... but I do not blame their IP stack for this like Mr Gibson does though.
Same here.
... From spoofed sources because ISPs do not source address filter? Gah. Basically untraceable.
This is the problem.
What should we do?
Recommendation: upgrade your peering requirements to include language like:
Each peer agrees to emit only IP packets with accurate source addresses, to require their customers to do likewise, and to extend this requirement to all other peers by $DATE.
Where DATE = (now() + '6 months') or some other negotiated value.
I've been saying this since 1993. Is anybody ready to believe me yet? We solve this, or our industry stops growing because we're spending too much time dealing with this problem and new customers see diminished returns.
-- ------------------------------------------------------------ Roland Dobbins <mordant@gothik.org> // 408.859.4137 voice