Some ideas on how to protect against longer-prefix hijacking

Sun Feb 24 23:31:23 UTC 2008

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. 

So, let's start with some observations (I'm very willing to be
corrected):

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.

So, here are a few proposals:

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20080224/bdd6da34/attachment.html>