Re: RIPE DB transition and RFC2725

[Andrei Robachevsky <]

"Lu, Ping" wrote:
> 
[snipped...]
> > > There are two seperate issues here:
> > > 1. The RFC doesn't say a implementation (like RIPE-DB v3.0)
> > should allow
> > > foreign references ( using objects from other RR database) or not.
> >
> > RFC does not prohibit foreign references.  As a matter of fact, RIPE
> > has a workaround that does this.
> >
> > Please also see the companion RFC RFC 2769 for making RFC 2725 checks
> > across registries. RFC 2769 and 2725 together yield a global
> > distributed registry. Of course, it requires cooperation form other
> > (at lease regional) registries.
> >
> 
> The wrokaround means DISABLE integrity checking. That's an option for
> RIPE-DB v2.x (RIPE-181)
> but we haven't tried RIPE-DB v3.x yet.
> 

I don't think that referential integrity is an issue here. The issue is
in getting proper authorization from the entity registered in a
"foreign" database/registry in order to perform route creation in the
RIPE database, i.e  a) holder of IP space (less specific route or
inetnum), b) owner of ASN (aut-num). The route itself should be
protected by "local" maintner registered in the RIPE database, so
referential integrity is safe.

> Also the workaround raises another question:
> How do you authorize the route creation from a foreign AS ?
> 

Exactly. All registries need to implement RFC 2769, or find another
coordinated solution.

> That's exactly the issue from Andrei's previous email (subject: Migration
> issues: route creation).
> And the solution to this needs to be discussed further.
> ( Hi, Andrei, any more suggestions from the community yet ?)
> 

Not many really. So far it boils down to:

1. Unprotect non-RIPE IP and ASN space. People will need to create
corresponding objects (inetnum, aut-num) in the RIPE DB.
Drawbacks:
- Duplicate information is registered. It will become outdated after
some time. Needs to be cleaned up.
- Security for such route registrations is as low as without rps-auth.

2. Slightly modified 1.
Create encompassing inetnum object with "mnt-routes:" protected by
mntner with NONE auth. This will eliminate need for corresponding
inetnum creation and will reduce amount of redundant information.
Registering an aut-num object is already required in v2.x (though no
authorization is checked), so this may work as interim solution.


Regards,

Andrei
PS I am speaking about RIPE IRR, but the same applies to other IRRs
willing to increase security level.


[snipped...]

> > > > Cheers
> > > > Frank
> > > >
> > > > --
> > > > Frank Bohnsack                       email  fb@localhost
> > > > UUNET, A Worldcom Company            phone  +49 (0)231 972-1495
> > > > EMEA Access & Backbone Networks      fax    +49 (0)231 972-1188
> > > > Team Dortmund                        web    www.de.uu.net
> > > >
> >
> >
> > Cengiz
> >
> > --
> > Cengiz Alaettinoglu           Packet Design
> >

-- 
Andrei Robachevsky
DB Group Manager
RIPE NCC