<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16608" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>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. </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>So, let's start with
some observations (I'm very willing to be corrected):</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>For North American
operators, long prefixes advertised 3 or more BGP hops away are frequently
forged.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>So, here are
a few proposals:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>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".</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=610005822-24022008>Just trying to offer
solutions that could be implemented easily. I'm sure many smarter than I can
come up with better ones.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=610005822-24022008></SPAN></FONT> </DIV></BODY></HTML>