[102678] in North American Network Operators' Group
Some ideas on how to protect against longer-prefix hijacking
daemon@ATHENA.MIT.EDU (Tomas L. Byrnes)
Sun Feb 24 18:56:50 2008
Date: Sun, 24 Feb 2008 15:31:23 -0800
From: "Tomas L. Byrnes" <tomb@byrneit.net>
To: <nanog@merit.edu>
Errors-To: owner-nanog@merit.edu
This is a multi-part message in MIME format.
------_=_NextPart_001_01C8773D.5AA1D59B
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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.
=20
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.
=20
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.
=20
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.=20
=20
So, let's start with some observations (I'm very willing to be
corrected):
=20
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.
=20
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.
=20
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.
=20
For North American operators, long prefixes advertised 3 or more BGP
hops away are frequently forged.
=20
So, here are a few proposals:
=20
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.
=20
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.
=20
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.
=20
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".
=20
Just trying to offer solutions that could be implemented easily. I'm
sure many smarter than I can come up with better ones.
=20
=20
=20
=20
------_=_NextPart_001_01C8773D.5AA1D59B
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16608" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D610005822-24022008>Fundamentally, this=20
is a policy issue, and the implementation details will need to be worked =
out,=20
but today's event with YouTube is an exclamation point on a problem many =
of us=20
have been wrestling with for some time: the advertising of unused =
but=20
non-bogon address space by cybercriminals.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D610005822-24022008>Whether accidental=20
or not, the black-holing of Youtube by Pakistan Telecom demonstrates a =
serious=20
weakness in the "longest prefix wins" rule: there is no concept of =
trust=20
contained in it.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>Trust, =
whether=20
implicit or explicit, is inherent in all human interactions, yet =
expressing it=20
in cyberspace has continued to be troublesome. In routing decisions, =
once you=20
are beyond a connected (either directly or multi-hop) peer, it becomes =
much more=20
difficult.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>I'm =
going to stay=20
away from the political issues here, because I've been told to, but I =
think they=20
really need to be weighed. Just as the companies we each work for or run =
take=20
into account the regulatory framework and rule of law in the =
jurisdictions in=20
which we do business (and use those as metrics on whether to do business =
at all=20
in many places), I think it is wise to take those items, as well as =
other=20
matters that play into trustworthiness, into account when choosing to =
accept=20
routing information. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>So, =
let's start with=20
some observations (I'm very willing to be =
corrected):</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>Due to =
history and=20
network geography, the distribution of longer prefixes is not uniform in =
the=20
Internet. While there are exceptions, the vast majority of /22s and =
longer are=20
in low-numbered ASes in North America, Europe, and=20
AUSNZ.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>Due to =
a greater=20
level of general civility, the prevalence of the rule of law, and the =
ability to=20
have recourse against rogue operators, the incidence of rogue routing=20
information from the locations above is orders of magnitude lower than =
that=20
outside of it.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>Most =
North American=20
Operators are, if not a full backbone themselves, directly =
connected to a=20
true backbone provider, and therefore only 2 hops to any serious=20
website.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>For =
North American=20
operators, long prefixes advertised 3 or more BGP hops away are =
frequently=20
forged.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>So, =
here are=20
a few proposals:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>1: Per =
my prior=20
message, create a "SuperAS" that highly trusted entities (like MS, =
Google,=20
Yahoo, etc) directly peer with, who everyone else peers with for routing =
information, from which ANY prefix-length will be =
accepted.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>2: =
Have some sort of=20
algorithm that inversely relates AS number to longest prefix accepted =
from. IE,=20
you would accept a longer prefix with 701 as the originator =
(not the=20
advertising peer) than 17557.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>3: =
Filter prefixes=20
longer than some constant * number of ASes in path, as opposed to some =
raw=20
filter. Do not aggregate, simply do not import at all. I'd say that you =
should=20
accept /24 only from 2 hops or less, /20 from 3, and =
maximum/default from=20
beyond.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>These =
are simple=20
ideas on how, without adding a whole lot of complexity, we might address =
some of=20
the issues highlighted by today's "accident".</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D610005822-24022008>Just =
trying to offer=20
solutions that could be implemented easily. I'm sure many smarter than I =
can=20
come up with better ones.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D610005822-24022008></SPAN></FONT> </DIV></BODY></HTML>
------_=_NextPart_001_01C8773D.5AA1D59B--
