hierarchical auth with route objects
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, thank you for starting the discussion. Here are my 2 cents worth. I firmly believe that authorisation in the database should follow authority in the real world. In practise the administrator of an AS has the exclusive autority which routes to originate. Therefore the authorisation to create route objects should be linkt to the aut-num object referred to in the origin attribute of the route object to be created and nothing else. This can be implemented by defining the mnt-lower attribute of the aut-num object to control all such route creations. It has been noted that it would be useful to involve the user of the address space covered by the route somehow as well. I believe that a notification scheme would be sufficient here. Authorisation is not necessary. I have not thought out a hierarchical notification scheme. Here are a few things to consider: - Notification should only occur if requested by an attribute in the object which is hierarchically higher. - one might consider to make notification of overlapping *routes* without request, but the conditions should be well specified. - route creation notification should be possible for both other routes covering the same address space and inetnums covering that address space. - the creator of the route should be notified of the notifications as well, so that he can also take the initiative to coordinate So far my 0.02s worth. I would be interested to hear what people with complex ASes think about this. Daniel
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
participants (3)
-
Curtis Villamizar -
Daniel Karrenberg -
Schmitz＠RUS.Uni-Stuttgart.DE