North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

[doable?] peer filtering (was Re: Trusting BGP sessions)

  • From: john heasley
  • Date: Wed Nov 15 14:28:00 2000

i think all agree that filtering large/teir 1 peers (let's assume teir 1 is
defined as a peer who sends a large number of routes, ie: ignore the
business BS) the way customers are/should be filtered (by exact match prefix)
is impossible with the hardware (and/or implementations) available today.

then, assuming that these teir 1's are filtering their customers by prefix
collected from the/a IRR, then most routes are registered and the work
necessary by these teir 1s to register and maintain route objects for
their aggregates (as-path origin ^$) and an as-set is minimal.

i know that not all teir 1s are filtering this way or register their
aggregates, but is there really an excuse not to?  esp today, when we
have merit's IRRd (or BIRD from ISI? and others) at our disposal, such
that we can maintain our own IRR and mirror the [RPSL] databases of
others _and_ there are at least 2 publically available databases (RADB
and ALTDB).  ok - sticking my foot in the business BS just for a 
moment - registration could easily be a peering contract requirement.

[here's the beef]
it should be possible to have an [daily] automated process (such as we
have for building customer prefix filters) which for a set of teir 1
peers, queries the IRR for a peer's as-set reducing it to a number of
routes * .NN (where NN is say 10%, or graduated or whatever - allowing
for some flux between runs of the collector) and applies this number
as the maximum-prefix for that peer.

the only drawback i can think of is that if the advertised prefixes
from a peer ligitimately exceeds the estimation (eg: add a customer
advertising a large number routes) the peering would have to be reset,
the peer would have to soft-clear outbound, or see
draft-ramachandra-bgp-restart-04.

this doesnt protect one from prefix hijacking, but it does reduce the
affects of redistribution accidents and the like and is doable.

ignoring kinky transit arrangements, it is possible to further restrain
by as-path of teir 1 peer X, by not accepting as-path ^(Y|Z)_