Christopher L. Morrow wrote:
> I'm going to take a stab at: The next 184.108.40.206/8 release? Certainly there
> was some lesson learned from this, no?
I don't buy it, Chris. Are you saying that a large backbone provider
can't maintain up-to-date bogon filters? In fact, I'd say they would be
better at it, and if they were using the filters, then there would be
less need for their customers to apply the filters and we'd have less
bogon issues in the future.
Owen DeLong wrote:
> Source address-based filtering in the backbone is expensive and, in
> many cases, non-feasible.
Most vendor equipment is easily capable of handling bogon filtering
using any number of methods. This is particular true when filtering
packets that are not announced bogons (such as most dDOS spoof attacks),
even if announced bogon packets are allowed through.
Certain backbones _rely_ upon bogons in order for their anti-spoof
tracking to work, rather than simply filtering the spoofing to begin with.
Backwards logic, but certain backbones seem to be set in their ways
and unwilling to change.
unwilling to use IRR data to build customer route filters, and instead
requiring emailed, manually applied updates (hack spit)
unwilling to filter even the most blatant of bogons
unwilling to do even loose RPF
I've been recommending competing backbones which seem to get
at least some of those right.