Comments followed. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu@cw.net
-----Original Message----- From: Cengiz Alaettinoglu [mailto:cengiz@packetdesign.com] Sent: Friday, March 09, 2001 11:24 AM To: Lu, Ping Cc: 'Frank.Bohnsack@de.uu.net'; db-wg@ripe.net Subject: RE: RIPE DB transition and RFC2725
Lu, Ping (plu@cw.net) on March 9:
Finally somebody express the same concerns as ours.
I have a discussion with the RIPE staff at the RIPE-38 meeting about this.
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. Also the workaround raises another question: How do you authorize the route creation from a foreign AS ? 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 ?)
2. The assumption of RIPE-DB v3.0 is that all object references have to be resloved locally( ie. with source: RIPE).
The 2nd issue means if any ISP with ARIN's AS number want to register a route with RIPE you have to register your PN(person) then your MT(mntner) then your AN(aut-num) with RIPE first.
So each ISP has to maintain a different set of objects with each RR. AS123(in RIPE) -> MNT-AS123-RIPE -> NIC456-RIPE AS123(in ARIN) -> MNT-AS123-ARIN -> NIC456-ARIN AS123(in APNIC) -> MNT-AS123-APNIC -> NIC456-APNIC AS123(in JP) -> MNT-AS123-JP -> NIC456-JP AS123(in DE) -> MNT-AS123-DE -> NIC456-DE ....
Just to remember to update all these information everytime there is a little tiny change. It is fun, isn't it ?
And NO you can't get all route information from just one RR unless we all sit down and seriously talking about the GLOBAL issues.
Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu@cw.net
-----Original Message----- From: Frank Bohnsack [mailto:Frank.Bohnsack@de.uu.net] Sent: Friday, March 09, 2001 7:43 AM To: db-wg@ripe.net Subject: RIPE DB transition and RFC2725
Dear colleagues,
Yes, I know the deadline for transition comments is over, but after studying RFC2725 we need a confirmation for our understanding.
RFC2725 defined the need for an "as-block" object for each related "aut-num" object and an "inetnum" object for each related "route" object.
The assignment of AS blocks and IP space is managed by IANA. * http://www.isi.edu/in-notes/iana/assignments/as-numbers * http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space
Does the new RIPE DB manage only "as-blocks" and "inetnums" which are assigned to RIPE ?
1/ And if I'm right, is it true that we can't store our ASes 702, 1270 and a lot of routes (assigned to ARIN) in the new RIPE database ?
2/ And is it true that we therefore can't set our route (assigned to RIPE) objects origin to our ASes ?
The solution for 1/ is moving to ARIN, but what might be the solution for 2/ ?
You say a big ISP is anyway talking to multiple IRRs, but I think customers who want to peer with these can't get complete information while using RIPE DB only.
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
"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
participants (2)
-
Andrei Robachevsky -
Lu, Ping