RIPE DB transition and RFC2725
- Previous message (by thread): RIPE DB transition and RFC2725
- Next message (by thread): RFC2725
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Andrei Robachevsky
andrei at ripe.net
Fri Mar 9 18:44:40 CET 2001
"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 at de.uu.net > > > > 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
- Previous message (by thread): RIPE DB transition and RFC2725
- Next message (by thread): RFC2725
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]