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