[102681] in North American Network Operators' Group
RE: Some ideas on how to protect against longer-prefix hijacking
daemon@ATHENA.MIT.EDU (David Freedman)
Sun Feb 24 19:37:18 2008
Date: Mon, 25 Feb 2008 00:16:01 -0000
From: "David Freedman" <david.freedman@uk.clara.net>
To: <nanog@merit.edu>
Errors-To: owner-nanog@merit.edu
This is a multi-part message in MIME format.
------_=_NextPart_001_01C87743.E368E42F
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
>1: Per my prior message, create a "SuperAS" that highly trusted =
entities
How do we qualify those, are they linked to the amount of revenue we =
would lose from customers
if they can't reach them? Can I be one of those? :)
>2: Have some sort of algorithm that inversely relates AS number to =
longest prefix accepted from
AS Number? these things are not related and this is not useful.
RIRs such as the RIPE NCC have recommendations about the longest prefix =
they will "allocate" to an LIR=20
from a particular /8, see document RIPE-415 section 4
>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.
This is simply not practical, networks usually have little control over =
how many ASNs sit between them and networks they want to reach, this is =
a matter of routing policy.
Also, IRR filtering, whilst a wonderful idea, is hugely impractical as a =
blanket suggestion, mainly down to untidy IRR data and sheer numbers of =
prefixes involved as you look at some of the larger networks.
For instance, I did a brief study of the top 5 peers at the LINX by =
prefix count recently, unrolling their IRR Macros yielded nearly 330k =
prefixes=20
Since we all already started developing a secure framework for BGP , I =
think we should just pick up the pace a little on this, if anything.=20
Dave.
------_=_NextPart_001_01C87743.E368E42F
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>RE: Some ideas on how to protect against longer-prefix =
hijacking</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=3D2>>1: Per my prior message, create a =
"SuperAS" that highly trusted entities<BR>
<BR>
How do we qualify those, are they linked to the amount of revenue we =
would lose from customers<BR>
if they can't reach them? Can I be one of those? :)<BR>
<BR>
>2: Have some sort of algorithm that inversely relates AS number to =
longest prefix accepted from<BR>
<BR>
AS Number? these things are not related and this is not useful.<BR>
<BR>
RIRs such as the RIPE NCC have recommendations about the longest prefix =
they will "allocate" to an LIR<BR>
from a particular /8, see document RIPE-415 section 4<BR>
<BR>
>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.<BR>
<BR>
This is simply not practical, networks usually have little control over =
how many ASNs sit between them and networks they want to reach, this is =
a matter of routing policy.<BR>
<BR>
Also, IRR filtering, whilst a wonderful idea, is hugely impractical as a =
blanket suggestion, mainly down to untidy IRR data and sheer numbers of =
prefixes involved as you look at some of the larger networks.<BR>
<BR>
For instance, I did a brief study of the top 5 peers at the LINX by =
prefix count recently, unrolling their IRR Macros yielded nearly 330k =
prefixes<BR>
<BR>
Since we all already started developing a secure framework for BGP , I =
think we should just pick up the pace a little on this, if anything.<BR>
<BR>
Dave.</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C87743.E368E42F--
