hierarchical route objects, part 1

In message <9701161658.AA22511 at 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