|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Some ideas on how to protect against longer-prefix hijacking
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.
|