Re: Peer Filtering

[Nick Hilliard <nick () foobar org>]

> That was one of our biggest worries.... people make mistakes and route
> leaks happen.....

They do.  And it's not just mom+pop providers who occasionally leak an
entire table.  Big operators do it too.

> The unfortunate part we're faced with now is that we have several
> downstream customers who are multihomed.  Because we're filtering out
> some of the prefixes that are not in an IRR, those routes are not nearly
> as attractive downstream giving the other carrier involved an
> advantage..... I can see this is where convenience/economics start to
> kick in ;(

One way or another, if you're providing transit, you absolutely need some
means of filtering your downstreams using prefix filtering, and also
preferable ASN filtering.  Otherwise, your downstreams can inject any sort
of crap into your table and you're opening yourself up to
I-can't-believe-it's-not-youtube-hijacking-again situations.  This is
really bad and harmful for the internet.  Max-prefixes are fine for peering
exchanges, where you can just depeer if there's a problem, but they will
not protect you against customers doing stupid stuff.

The only issue for customers is not whether you do prefix filtering but
whether you use IRR information or maintain your own internal database.
The latter is re-inventing the wheel, imo.  But lots of companies do it anyway.

If your peering exchange doesn't provide multilateral peering, ask them to
do so.  This provides a natural platform for using route server client IRR
prefix filtering, and route servers (despite a lot of well known and
understood problems associated with them) can be very useful in this regard.

Nick