Some ideas on how to protect against longer-prefix hijacking

David Freedman david.freedman at uk.clara.net
Mon Feb 25 00:16:01 UTC 2008


>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20080225/d69bd21c/attachment.html>


More information about the NANOG mailing list