Hi again, Here is another brief proposal for your perusal. This time for an implementation of hierarchical authorization in the Routing Registry. The mechanism described below will implement a hierarchy in the RR for which I believe there is consensus. The ideas in the proposal below were sifted from discussions which took place on the <routing-wg@ripe.net> mailing list and in the Routing WG meetings at RIPE-25 and RIPE-26. Please review this if you have time. We are hoping to have a go ahead on this from the Routing and Database WG's at or shortly after RIPE-27. Greetings, Carol Orange RIPE NCC -------------------------------------------------------------------- Hierarchical Authorisation in the RR Proposal for an Implementation Carol Orange, May 1997 At the January meeting of the Routing WG in Amsterdam, various possible hierarchies for authorization in the Routing Registry (RR) were considered. Whereas extensive discussion took place on the extent to which authority can be established in the RR, there was clear agreement that the maintainer of an AS should have authority over what routes are announced with a given aut-num in the "origin:" attribute. In the following, we specify an implementation to support the authority of "aut-num:" maintainers to determine who can announce routes under their AS. The mechanism can be extended as the need arises and consensus on other forms of authorization is achieved. For more information on the discussions leading up to this proposal, see: http://www.ripe.net/wg/routing/haro-d.html. Implementation -------------- If you (or your organization) manages an AS, then you should have authority over the routes announced in your AS. This can be implemented if we: a) add a "mnt-lower:" attribute to the aut-num object b) allow routes to be announced with a given "origin:" by those given authority as defined in the mntner object specified in the "mnt-lower:" attribute of the aut-num object. Example ------- If we add a "mnt-lower:" attribute to the aut-num object of the RIPE NCC, then only those who know what peEw8Gb4xBNqI encrypts can add and remove routes originating in AS3333. ---- aut-num: AS3333 ... mnt-lower: AS3333-MNT ... ---- mntner: AS3333-MNT descr: RIPE-NCC Maintainer ... auth: CRYPT-PW peEw8Gb4xBNqI ... ---- route: 193.0.0.0/23 descr: RIPE-NCC origin: AS3333 ... Summary ------- Other forms of hierarchical authorization and notification can be implemented in the future if a well defined hierarchy can achieve consensus. To provide some initial functionality which may meet the needs of many RR users, we propose to implement the above in the short term.
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
Hi Curtis, Curtis Villamizar writes:
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.
The proposal is not intended to address the question (or provide an implementation) of authorization based on the CIDR prefix hierarchy. There remains much controversy on that point, which I was specifically trying to avoid in order to make progress in an agreed upon direction. My proposal is intended to provide some clearly desirable form of authorization, which everyone seems to want, while the issues surrounding CIDR prefix hierarchical authorization get settled. Perhaps the title "AS Route Announcement Authorization" would be more accurate? Greetings, -- Carol
participants (2)
-
Carol Orange -
Curtis Villamizar