In message <9611291742.AA17791@jade.noc.dfn.de>, 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@noc.dfn.de 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