Hierarchical Authorisation in the RR

> Hierarchical Authorisation in the RR
> Proposal for an Implementation 
> 
...
> 
> a) add a "mnt-lower:" attribute to the aut-num object


Carol,

This proposal is inadequate.  The whole point of hierarchical
authorization is to add some checks to the CIDR prefix (radix tree)
hierarchy which this does not address at all.

A simple step in the right direction would be to use the mnt-by in the
route object of an overlap if an overlap occurs.  A new route object
not overlapped by anything in the same database would be constrained
by the mnt-by in the aut-num it was registered for.  If an overlap or
an existing exact match occurs, then the intersection of authorization
for the aut-num and the overlap would be needed.

This makes it possible for an orderly handoff of authorization for a
more specific prefix.

Here is an example:

  as65001	maintained by [people in provider as65001]
    x.y/16	maintained by as65001

  situation:
    x.y.z/24 changes providers to as65002

  solution:
    1.  as65001 adds x.y.z/24 origin:as65001 and puts as65001 and
	as65002 in RO mnt-by
    2.  as65002 adds x.y.z/24 origin:as65002
    (note x.y.z/24 origin:as65001 is left as a renumbering reminder)
      -after renumbering grace period-
    3.  as65002 removes x.y.z/24 origin:as65002
    4.  as65001 removes x.y.z/24 origin:as65001

  situation:
    x.y.z/24 dual homes to as65002 using dual origin AS method

  solution:
    1.  as65001 adds x.y.z/24 origin:as65001 and puts as65001 and
	as65002 in RO mnt-by
    2.  as65002 adds x.y.z/24 origin:as65002
    3.  (optional) as65001 drops as65002 from x.y.z/24 origin:as65001
        RO mnt-by

  situation:
    x.y.z/24 dual homes to as65002 using as65003 origin

  solution:
    1.  as65001 adds x.y.z/24 origin:as65001 and puts as65001 and
	as65003 in RO mnt-by
    2.  as65003 adds x.y.z/24 origin:as65003
    3.  as65001 deletes x.y.z/24 origin:as65001

Some of the advantages:

  1.  The origin AS of the less specific never needs to give another
      AS authorization for their origin or for RO other than the
      prefix affected.

  2.  No one can add a more specific underneath an aggregate without
      the permission of the aggregate owner (like addr allocation).

  3.  No new fields are needed.

  4.  The only change is to the authorization procedure for route
      objects.

Disadvantages are:

  1.  Same as advantage #2 if there is an unresponsive object
      maintainer.

This isn't perfect because there is no protection from entry into
another database.  That will have to be solved in some other way since
it is only solvable if address allocation information is present and
tied to the route object entry (and it may require dual signature).
Even then if one database fails to recognize another, the multiple
database problem is made even more difficult.

Curtis