On 5-dec-04, at 20:03, Rob Thomas wrote:
] - That's only some 40% of all address space, so you need to be able to
] deal with the other 60% anyway. Why wouldn't whatever mechanism that
] deals with the 60% be unable to deal with the additional 40%?
In a study of one oft' scanned and attacked site, we found that 66.85% of the source IPs were bogon (RFC1918, unallocated, etc.).
Well, I didn't keep a running total, but I'd say that in the attacks that I've dealt with 80%+ used real addresses or something indistinguishable. I understand this is what most people see. So unless someone has data that indicates otherwise, I'll assume your experiences are an exception.
Filtering out bogons removes yet one more potential source of badness.
...while at the same time introducing a new one: the risk of filters going un-updated. (Generally speaking. For a BGP feed from you this isn't much of a risk.)
] - (Loose) uRPF will buy you the exact same functionality and more ] without any upkeep.
Even with uRPF one needs to keep the RIB clean.
Yes, but how do you do that without an authoritative prefix->AS mapping? (And good tools. I know there are some, but I find them too hard to work with.)
<http://www.cymru.com/Documents/secure-bgp-template.html>
Note though that so far, nobody has tried to inject bogon routes into the global routing table just so packets from bogon sources wouldn't be filtered. The reason we want this is because of address space hijacking (such as done by spammers) and configuration mistakes. So filtering at the /8 level as in the document linked above isn't really going to buy you much in practice.
