Re: algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters

[Paul Thornton <prt () prt org>]

On 04/02/2016 11:14, Martin T wrote:
> Hi,
>
> am I correct that ISPs (in RIPE region), who update their BGP prefix
> filters automatically, ask their IP transit customer or peering
> partner to provide their "route"/"route6" object(s) or "as-set" object
> in order to find all the prefixes which they should accept? If the IP
> transit customer or peering partner provides an "as-set", then ISP
> needs to ensure that this "as-set" belongs to this IP transit customer
> or peering partner because there is no automatic authentication for
> this, i.e. anybody can create an "as-set" object to database with
> random "members" attributes? This is opposite to "route"/"route6"
> objects which follow a strict authentication scheme. In addition, in
> case of "as-set", an ISP needs to recursively find all the AS numbers
> from "members" attributes because "as-set" can include other
> "as-sets"? Quite a lot of question, but I would simply like to be sure
> that I understand this correctly.

Yes you do.  Typically, you'll tell the transit provider something like 
"We are AS23456 announcing AS-STUFF" at order time so they know what to 
look up.

What then happens is they have something that does the following as 
either a semi-automatic or fully automatic process:
1) Iterate through AS-STUFF to get a unique list of AS numbers that are 
involved.
2) Go through this list of ASes, doing an inverse lookup of route or 
route6 objects with an origin of those ASes.
3) Create filter list from the above list.

The route/route6 objects actually have very weak authentication for 
out-of-RIPE-region prefixes.

For example, if I want to add a route object for ARIN prefix originating 
from my RIPE-region AS, there is a dummy maintainer to make this 
possible.  This is currently subject to somewhat of a debate on the 
mailing lists because of the obvious abuse vector, and there are cases 
where this has been used to help "legitimise" address space hijacks.

Unfortunately it is hard to simultaneously allow legitimate 
unauthenticated use without allowing abusive route objects.  Which is 
why there is a lot of head-scratching here; I don't have an answer to 
that one.

Paul.