as you say for customers only. Inter-provider we have basic bogon checking plus maximum prefix. Its too unwieldy to build when you have peers exchanging thousands of routes... theres a belief that the peer should be behaving responsibly tho and this is a condition of most bilateral peering contracts.
Unfortunately, contracts don't fix mis-(or malicious-) configurations on compromised routers or from a peers disgruntled worker.
Going back to the original topic on this thread I would expect a deliberate attack on BGP routing to come from a customer not a provider such as Level3, if they are filtering in turn to their customers we have a reasonable amount of sanity checking going on
A large provider I worked for in the past had a router maliciously configured to inject a more-specific prefix for a very "popular network". Even the "popular networks" provider sent the traffic to us. Had explicit prefix-based inter- provider filtering been in place it would not have occurred, or at least "the whole Internet" wouldn't have been affected. With the IRRs and inter-provider filtering it's the whole chicken and egg thing. Inter-provider filters aren't in place because no one cares about IRRs (even though they have other operational value as well). Vendors don't support the amount of prefix filters required because they say no one uses them. Heck, lots of folks still don't ingress filter routes (or packets) from their customers. When ANS used to employ inter-provider filters the biggest problem was getting them updated and bouncing routes or sessions. That's no excuse anymore because pretty much everyone supports the ability to incrementally update filters, and BGP Route Refresh fixes the bounce the session/route thing. So, let's recap why no one uses them (as many have said already in the related thread): Laziness. The same laziness that results in the slew of other things many folks have pointed out not being addressed. -danny