I think you're failing to take into account how multihoming generally
works. The real fallacy here is that PCCW/BTN refuses to prefix-list
filter their customers, as evidenced by this and past leaks. If
something productive can come from today's outage, it would be PCCW
beginning to do their part as responsible Internet citizens, given
(excuse the pun) "peer" pressure.
I'd also focus on the lessons learned from the un-official "IP
Hijacking BOF" held in San Jose, during which engineers and
researchers studied the extent to which obviously-bogus route
advertisements propagated across the public Internet. At these
events, prefixes such as 1/8 and 100/7 were advertised, and, by
Renesys/bgplay/route-views/etc data, accepted by >99% (?) of the
internet. IP blocks that were hijacked before (like 146.20/16) were
announced with similar outcome.
Results were planned to be presented at the next NANOG, but they
shouldn't be a surprise to anyone in the industry: nobody filters.
Paul Wall
Well, if they had problems like this in the past, then I wouldn't trust them to get it right. Which means that it's probably a good idea if EVERYONE starts filtering what they allow in their tables from PCCW. Obviously that makes it very hard for PCCW to start announcing new prefixes, but I can't muster up much sympathy for that.
So basically, rather than generate routing registry filters for the entire world, generate routing registry filters for known careless ASes. This number should be small enough that this is somewhat doable. (Although better tools for generating the filters would help, I tried generating filters from the RIPE db a few times but I couldn't figure it out using available tools and I didn't have the time to write my own.)
Iljitsch van Beijnum writes:
Well, if they had problems like this in the past, then I wouldn't
trust them to get it right. Which means that it's probably a good
idea if EVERYONE starts filtering what they allow in their tables
from PCCW. Obviously that makes it very hard for PCCW to start
announcing new prefixes, but I can't muster up much sympathy for
that.
So basically, rather than generate routing registry filters for the
entire world, generate routing registry filters for known careless
ASes. This number should be small enough that this is somewhat
doable. [...]
Maybe, but how much would that help?
So you suggest that we only need to filter against AS7007, AS9121, and
AS17557. Personally, those are among the ones I least worry about -
maybe I'm naive, but I'd hope they or their upstreams have learned
their lessons.
The problem is that nobody knows which of the other 25000+ ASes will
be the next AS7007. So I guess we have to modify your suggestion
somewhat and, in addition to filtering the "known-careless" also
filter the "unknown-maybe-careful" class. Oops, that leaves only the
"known-careful" class, which includes... my own AS, and then whom?