Fundamentally, this is a policy issue, and the implementation details will need to be worked out, but today's event with YouTube is an exclamation point on a problem many of us have been wrestling with for some time: the advertising of unused but non-bogon address space by cybercriminals.

Whether accidental or not, the black-holing of Youtube by Pakistan Telecom demonstrates a serious weakness in the "longest prefix wins" rule: there is no concept of trust contained in it.

Trust, whether implicit or explicit, is inherent in all human interactions, yet expressing it in cyberspace has continued to be troublesome. In routing decisions, once you are beyond a connected (either directly or multi-hop) peer, it becomes much more difficult.

I'm going to stay away from the political issues here, because I've been told to, but I think they really need to be weighed. Just as the companies we each work for or run take into account the regulatory framework and rule of law in the jurisdictions in which we do business (and use those as metrics on whether to do business at all in many places), I think it is wise to take those items, as well as other matters that play into trustworthiness, into account when choosing to accept routing information.

Due to history and network geography, the distribution of longer prefixes is not uniform in the Internet. While there are exceptions, the vast majority of /22s and longer are in low-numbered ASes in North America, Europe, and AUSNZ.

Due to a greater level of general civility, the prevalence of the rule of law, and the ability to have recourse against rogue operators, the incidence of rogue routing information from the locations above is orders of magnitude lower than that outside of it.

Most North American Operators are, if not a full backbone themselves, directly connected to a true backbone provider, and therefore only 2 hops to any serious website.

For North American operators, long prefixes advertised 3 or more BGP hops away are frequently forged.

1: Per my prior message, create a "SuperAS" that highly trusted entities (like MS, Google, Yahoo, etc) directly peer with, who everyone else peers with for routing information, from which ANY prefix-length will be accepted.

2: Have some sort of algorithm that inversely relates AS number to longest prefix accepted from. IE, you would accept a longer prefix with 701 as the originator (not the advertising peer) than 17557.

3: Filter prefixes longer than some constant * number of ASes in path, as opposed to some raw filter. Do not aggregate, simply do not import at all. I'd say that you should accept /24 only from 2 hops or less, /20 from 3, and maximum/default from beyond.

These are simple ideas on how, without adding a whole lot of complexity, we might address some of the issues highlighted by today's "accident".

Just trying to offer solutions that could be implemented easily. I'm sure many smarter than I can come up with better ones.