North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Some ideas on how to protect against longer-prefix hijacking

  • From: David Freedman
  • Date: Sun Feb 24 19:48:09 2008
Title: RE: Some ideas on how to protect against longer-prefix hijacking

>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
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

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.

Dave.