algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters
prt at prt.org
Thu Feb 4 11:34:03 UTC 2016
On 04/02/2016 11:14, Martin T wrote:
> 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
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
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
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
More information about the NANOG