If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or...
Then we can worry about IRR infrastructure hardening and accuracy and derive explicit data plane filters from the output, as well as other tangible benefits.
Is it really that hard?
I can see not filtering peers if the hardware can't handle it, but there doesn't appear to be such a good excuse for not edge filtering. If Barry Green is listening out there, I'd be interested to hear how successful he and his team have been at convincing ISPs to do this. I know he's been on his ISP Security Best Practices world tour for quite a while now, and am curious if he's found it more difficult to get edge filtering implemented vs. other security measures (and if so, why) or if it's just security in general that's difficult to get ISPs to do. Also, are recommendations given for how edge filters should be maintained? This was discussed here a short while ago but I don't think a broad consensus was reached. The mere existence of the filters is nice to prevent AS7007-like incidents but does little to prevent other bad things such as address hijacking if the customer (or someone posing as the customer?) can call the ISP and get holes punched in a filter for address blocks that he/she has no business announcing. It seems that a common practice amongst ISPs who do filter on the edge is to blindly punch holes in these filters when asked without somehow "validating" the request. Does this negate a significant portion of the advantages gained by edge filtering or are we primarily concerned with accidental/malicious route table leaking at this point? -Terry