Re: hierarchical auth with route objects

[Curtis Villamizar <]

In message <9611291742.AA17791@localhost>, Joachim Schmitz writes:
> 
>  Dear colleagues,
> 
>  hierarchical authorization in the RIPE-db as a new feature presented at
>  the last RIPE meeting is not limited to inetnum objects or the domain
>  name space. It is also applicable to route objects. However, it has not
>  yet been implemented for route objects because no consensus was found on
>  how to do it. With this mail I want to start the discussion again. Please
>  note, that this is only the draft of a draft - nothing final. So drop your
>  comments here!
> 
>  In my opinion, route objects are not much different from inetnum objects
>  regarding hierarchical authorization. Both span a certain range of IP
>  addresses and in both cases hierarchical authorization controls definition
>  of IP subranges. Following this reasoning it seems to be simple to implement
>  within the IP prefix tree.
> 
>  However, route objects are not standing alone but are logically linked to
>  AS objects via the origin tag. Applying hierarchical authorization within
>  the IP prefix tree *alone* does allow uncontrolled creation of route objects
>  of differing origin. Therefore, AS objects which match the origin AS of a
>  route object may be considered as parent objects of route objects. I think
>  this is a very useful approach (even though it links different types of
>  objects in one authorization hierarchy).
> 
>  There have been ideas that route objects should only be created if proper
>  address allocation occured. However, it has also been pointed out that it
>  is not a good idea to mix address allocation and routing for several rea-
>  sons, e.g. some registries are pure routing registries and all registries
>  should have the same structure. Moreover, changes in routing might make
>  changes in address registration necessary (and vice versa). There have been
>  some good comments on this topic on the database wg mailing list. Never-
>  theless, if no route objects exist for allocated address space, any AS
>  owner may generate route objects uncontrolled in this registry (creation
>  of objects in one registry which are protected by hierarchical authorization
>  in another is also not covered but this is an entirely different problem).
> 
>  Obviously, there are still some loose ends. But I think that the approach
>  of AS objects as parents of route objects from corresponding origin com-
>  bined with hierarchical authorization within the IP prefix tree is very
>  useful and may be applied here.  Shall we go for this?
> 
>  Regards
>     Joachim Schmitz
> _____________________________________________________________________________
> 
>  Dr. Joachim Schmitz                                   schmitz@localhost
>  DFN Network Operation Center
>  Rechenzentrum der Universitaet Stuttgart              ++ 711 685 5553 voice
>  Allmandring 30                                        ++ 711 678 8363  FAX
>  D-70550 Stuttgart                                     FRG (Germany)
> _____________________________________________________________________________


Joachim,

First let me compliment you on the excellent work RIPE and the
routing-wg has been doing and continues to do having created RIPE-181
and provided this and other extensions to it.

IMO: Applying hierarchical authorization to route objects is needed.  

There are two cases: 1) allocation is done by an IRR based registry
(RIPE) and therefore corresponding inetnum objects exist, and 2)
allocation is done outside of the IRR (InternNIC/RADB) and no inetnum
objects exists.  This affects the top level allocation.  In the second
case it must be added manually, similar to adding a maintainer.

Here's a suggestion.  

When checking authorization for a route object the operation is
accepted if:

  0) The submitter may have specific authorization for this route
     object.
  1) If there exists a less specific route object for which the
     submitter has authorization, as long as the origin AS is the
     same.
  2) If a different origin AS is used the submitter must have
     authorization for the current origin AS and the new origin AS.
     Dual origin AS prefixes is (IMO a bad idea, but..) a potential
     place where a dual PGP signature would be needed, one for each
     origin AS.  (PGP sign and forward to the other party, PGP sign
     and submit)
  3) Alternately, the submitter may have authorization for the inetnum
     and authorization for the origin AS.

In case 3, I'd like to see an exact match for the inetnum a
requirement.  If the entire allocation cannot be advertised as an
aggregate (people would like to know that and maybe they'd like to
know why at some point) then the top level route object can be marked
as withdrawn to indicate that it is not announced.

Curtis