--- Begin Message ---
Stefan Ideler via db-wg wrote:
> Being a member of multiple RIR's, the Ripe db is user friendly and a
> scriptable database. I don't want to divide my as-sets and prefix
> filter generation over 3 or more different database systems, with
> the additional maintenance and in some cases even less verification.
> Atleast my RIPE originating objects are secure and they make up the
> majority of my prefixes.
>
> As a result our route objects regardless of origin are noted in the
> RIPE database. Our upstreams use it to generate their prefix filters
> (and not all of them support multiple databases) and as a result we
> require all our downstream customers to have their AS/route objects
> within the RIPE database as well.
Several years ago, we planned this sort of approach via IXP Manager, but
when we wrote the code to do it, we realised that this was a very
limited and limiting mechanism for handling prefix list generation. It
caused a lot of extra work for us in terms of support requirements and
explaining to people that they had to do this. Several member
organisations refused to comply and said they had no intention of
changing their policies.
The result of this was that we ended up not carrying traffic that we
could alternatively have carried, and we annoyed our members.
Not the best idea, in retrospect.
We ended up having to be a lot more flexible on the issue. The best way
we found to handle it was to allow any customer to be associated with
any arbitrary IRR policy. E.g. one customer could use source: RIPE,
ARIN and RADB, and another could use LACNIC, ALTDB and LEVEL3.
It's actually pretty straightforward to implement this, and gives the
advantage that you're no longer creating extra work for customers by
forcing them to register their route: objects in IRRDBs where they
wouldn't otherwise do so.
The code for this is freely available on github.com/inex/IXP-Manager.
I'm mentioning this because there is a serious security problem
associated with permitting out-of-region objects in the RIPE database:
this causes repeated, serious security problems with routing leakage on
the Internet. This feature is being persistently abused by scammers and
other criminals and is devaluing the integrity of the data in the RIPE
IRRDB.
Unless this problem is fixed, it's going to continue to be a problem
indefinitely.
We cannot fix it unless people fix their code.
Nick
--- End Message ---
