[6bone] (OT but Relevant) Recent spammer tactics - BGP Hijacking

Andy Furnell andy@ipng.org.uk
Tue, 13 May 2003 07:58:31 +0100


On Mon, May 12, 2003 at 03:17:36PM -0400, John Fraizer wrote:
> 
> Andy,
> 
> Filtering on the transitAS<->transitAS side of things will always be
> painful and for most decent sized networks, it is not something that
> happens, even in the v4 world.
 
Maybe not in the states, but RIPE NCC seem to be pushing very hard to
have people make full use of the routing registries available. It may be
impractical (and unecessary) for Tier 1s peering with each other to
filter routes with such granularity, but there are plenty of other ISPs
further down the food chain who filter down to individual
prefixes/as-paths for their peers as well as their customers; filters
which have served them well to protect not only their network but The
Internet community at large.

> Filtering "customer" or "customer-like" peering sessions is a different
> story though.  If someone "doesn't have time" to implement responsible
> filtering on their customer sessions, they shouldn't IMNSHO be speaking
> BGP to begin with.

Apologies if my mail came across in the wrong way. I wasn't implying
that people shouldn't filter customer routes... totally the opposite.
 
> With appropriate "customer" filters in place on the customer-facing edge,
> border filters on the peering border are something that in most cases are
> not needed.  

In a perfect world this would be true. But mistakes do happen, and IME
if you don't want these mistakes to affect you, you need to filter
everywhere possible. It also encourages your peers to keep their
information current in a routing registry, which in turn makes it much
easier to verify information you can see from a given AS.

> If someone "leaks" something to us once, we will help them establish
> appropriate policy to prevent future "leaks."  If they do it twice, they
> face the wrath of "neighbor [x.x.x.x|xx:xx:xx:xx] shutdown" on our
> side.  It tends to get them thinking in a more responsible manner and if
> NOT, they're not the kind of peer we wish to interact with.

Sure, but can we at least agree that a routing registry for IPv6
prefixes would make this job a little easier? :)

-- 
Andy Furnell
andy@ipng.org.uk