In message <9701161658.AA22511@jade.noc.dfn.de>, Joachim Schmitz writes:

Dear Curtis,

you wrote:

...

...

...

Here is an example. The registries approve of the top level blocks, that is the aggregates (or blocks that should be announced as aggregates). Whoever the aggregate is allocated to creates the top level route object and can delegate below that. For example, ANS has 207.24/14. There were two route objects needed to handle multihomed (a /22 and a /24) prefixes. The usual way a provider would delegate would be to reference more than one maintainer in the route object (the provider and the customer, and probably the other provider if the route object had a unique origin AS).

This scheme sounds reasonable but it raises the question of coordination among different registries...

I would not expect to see the same address space allocated by more than one registry. All registries would have a top level 0/0 route object which prevents registry of bogons. RIPE would have a hierarchy under 0/0 and the RA would have a hierarchy tracking InterNIC assigned addresses. I would not expect the two to overlap, therefore there is no real coordination problem beyond initial setup or new blocks allocated to a registry.

This is more difficult than it looks from the beginning. As an example we ourselves register all our objects (inetnum, routes, persons...) in RIPE database (because we are in Europe). However, among others we peer with MCI and MCI insists on having route objects in their registry in order to allow routing. If the route objects are secured by hierarchical authorisation in the RIPE database we would also like to have them secured in the MCI registry. Following the scheme above MCI would have to include inetnums (while it is a pure routing registry) *and* would have to generate top level route objects allowing specific access by us to our route objects (this is a very tiring job especially regarding "the swamp" 192.x). Of course, they could copy from RIPE database... (ask them why they don't... ) I guess, this problem may only be resolved by the GRR (which is yet to come)

I was thinking more in terms of the RADB problem. I was aware that MCI had been insisting on customer routes being in the MCI database but we have not been impacted since MCI does not (cannot with Cisco) filter on peerings at all. Perhaps someone from MCI can comment of why they refuse to import information from the RIPE database.

From the ongoing disussion I conclude for myself (at the current state of the discussion) that we can not impose a strict security mechanism at the time being without breaking too many things. Maybe, I am too dumb to see a simple solution which might be just at hand...

Perhaps MCI would be willing to import inet-nums from RIPE as long as the inet-nums fall within a given range. If they do a one time import of the swamp from the InterNIC, that should take care of the swamp. Another option is that only registries with inet-nums enable the authorization based on inet-num.

I will summarise the things said here on the mailing list for the routing wg session next week and try to think some more about it (I guess, Daniel was right from the start when he said that we should begin with a bare notification mechanism...)

Perhaps RIPE can do a hierarchical authorization within the RIPE DB. The RA can do so if they are willing to generate inet-nums based on InterNIC data and the same applies for MCI, or ANS for that matter. Otherwise the other registries would simply disable the feature.

Regards Joachim

Thanks for your patience and thoughtful responses. Best Regards, Curtis