"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@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