Dear all, We are already talking for quite some time about a hierarchical authorization scheme for objects in the RIPE database that need protection against creating objects in somebody else's address/domain space. Hereby, I want to describe the requirements for such a new feature and two possible solutions. Problem description: Currently, we see more and more problems with objects that are (usually by accident) created in another registries address space or problems with domain objects where people think that a domain is delegated to them when they have send a domain object to the RIPE database. It seems that, since we are using to much time for this kind of issues, the time has arrived that we need to solve the problem. Requirements: Objects that are directly located in a predefined hierarchy under a certain object need an extra authorization step before they can be created. The authorization step should be defined by the object that is located in the hierarchy directly above the object. The authorization step will be done on all objects that are located directly above the object if we have more then one object directly above the object (this should generally not be the case). The hierarchical authorization step seems not to be needed (yet) for updating/deleting an object in the hierarchy. However, the design should be able to be extended in such a way that this feature can be added in the future if the need arises. Currently we are dealing with three hierarchies: 1) Domain space hierarchy The definition of the domain hierarchy is straight forward: A domain consists of text strings concatenated with dots An domain is 'above' another domain when all text strings match with the other domain from the right and they are not the same. An domain is 'directly above' another domain when it is above the other domain and differs only with one text string. The definition for '(directly) below' another domain follows from the definition for above: An domain is '(directly) below' another domain when the other domain is above the domain. Example: 'x1.office.ripe.net' is below 'ripe.net' 'x1.office.ripe.net' is directly below 'office.ripe.net' 'ripe.net' is above 'x1.office.ripe.net' 'office.ripe.net' is directly above 'x1.office.ripe.net' 2) IP address space range hierarchy for 'inetnum:' objects An IP address space range is a little bit more complicated since we can have overlapping ranges: A range is 'above' another range when the range is larger then the other range and it overlaps it completely. A range is 'directly above' another range when it is the smallest possible range that is still above the object. The definition for '(directly) below' another range follows from the definition for above: A range is '(directly) below' another range when the other range is above the range. People might consider that there exists a problem when we are dealing with partially overlapping ranges (not possible with prefix notation ranges but are possible with normal IP address space range notation). However, the definition handles this problem gracefully: a range can only below or above another range when they overlap each other *completely*. Example: In IP address space range notation: '194.0.0.0 - 194.255.255.255' is 'above' '194.5.20.0 - 194.5.20.255' '194.5.20.0 - 194.5.23.255' is only 'directly above' '194.5.20.0 - 194.5.20.255' when there are no other ranges that are bigger and also 'above' '194.5.20.0 - 194.5.20.255'. '194.5.20.0 - 194.5.20.255' is 'below' '194.0.0.0 - 194.255.255.255' '194.5.20.0 - 194.5.20.255' is only 'directly below' '194.5.20.0 - 194.5.23.255' when there are no other ranges that are 'above' '194.5.20.0 - 194.5.20.255' and 'below' '194.5.20.0 - 194.5.23.255'. In prefix notation ranges: '194/8' is 'above' '194.5.20/24' '194.5.20/22' is only 'directly above' '194.5.20/24' when there are no other ranges that are bigger and also 'above' '194.5.20/24'. '194.5.20/24' is 'below' '194/8' '194.5.20/24' is only 'directly below' '194.5.20/22' when there are no other ranges that are 'above' '194.5.20/24' and 'below' '194.5.20/22'. 3) Route object hierarchy At first sight a 'route:' object has the same hierarchy as for 'inetnum:' objects. However, a 'route:' object has in fact a two level hierarchy: The origin AS object is always the object directly above a certain 'route:' object. An all route objects with a given origin are always directly below the origin AS object. Proposed solutions: 1) New attribute for hierarchical organized objects: Add an optional multiple line attribute to hierarchical organized objects that points to the maintainer object which authorization scheme will be used when an object will be created 'directly below' the object. mnt-lower: MAINTAINER [ ( CREATE & CHANGE & DELETE ) ] MAINTAINER - The maintainer that defines the authorization scheme to be used when an object 'directly below' in the hierarchy from the object, that has defined this attribute, will be created in addition to the authorization schemes that are defined in the to be created object itself. The maintainer will optionally be followed by a specification upon which events the authorization needs to be used: CREATE - perform the authorization step when an object is created 'directly below' the object. CHANGE - perform the authorization step when an object is changed 'directly below' the object. DELETE - perform the authorization step when an object is deleted 'directly below' the object. When no events are specified, the default behavior will be used, that is: perform the authorization only upon creation of objects directly below the object. This attribute is optional for objects that have a hierarchy defined. Currently, there is a hierarchy defined for: 'domain', 'route' and 'inetnum' objects. Multiple attributes may be defined and will mean that at least one of the authorization methods as mentioned in the referenced maintainers should allow the database update. Example: RIPE can have the following object: inetnum: 194.0.0.0 - 194.255.255.255 descr: RIPE - ALLOCATED BLOCK mnt-by: RIPE-NCC-MNT mnt-lower: RIPE-NCC-MNT (CREATE | DELETE) RIPE can allocate address space to a local registry and hand over the authority for the address space below. Note that the registry can not delete or create it's allocated address space object but may change it's contents. inetnum: 194.10.0.0 - 194.10.255.255 descr: ALLOCATED BLOCK to LOCAL REGISTRY mnt-by: LOCAL-REGISTRY-MNT mnt-lower: LOCAL-REGISTRY-MNT (CREATE | DELETE) Then the registry can register it's customers as follows: inetnum: 194.10.3.0 - 194.10.3.255 descr: CUSTOMER of local registry The customer may change their object but cannot create/delete it: 2) New attribute for maintainer object: Another solution would be to add an optional multiple line 'scope:' attribute to the maintainer object that will specify that the authorization scheme should be used when objects are created, changed or deleted 'directly below' the object that references the maintainer. At first glance, this solution looks attractive but will not allow for hand-over of authority as can be done in the first proposal. scope: WORKINGAREA [ ( CREATE & CHANGE & DELETE ) ] WORKINGAREA - Can be LOCAL or LOWER. LOCAL is the default behavior and is the same as the 'maintainer' object currently works. LOWER would do the authorization step when objects are created, changed or deleted directly below the hierarchical object that references the maintainer. CREATE, CHANGE, DELETE will work as specified in the previous proposal. Note that it will also extend the possibilities for the maintainers when used in LOCAL mode (the way maintainers work now): 'LOCAL (CREATE & CHANGE & DELETE)' matches the current maintainer behavior. The attribute is optional for maintainer objects. We could decide to allow the use of this attribute also for the hierarchical organized objects. It will then override the default behavior as specified in the maintainer object. The attribute can be used twice: one time for the LOCAL scope and one time for the hierarchical authorization method (LOWER). Example: RIPE can have the following object: inetnum: 194.0.0.0 - 194.255.255.255 descr: RIPE - ALLOCATED BLOCK mnt-by: RIPE-NCC-MNT mntner: RIPE-NCC-MNT scope: LOCAL (CREATE & CHANGE & DELETE) scope: LOWER (CREATE & DELETE) RIPE can allocate address space to a local registry and hand over the authority for the address space as below. Note that the registry can not delete or create it's allocated address space object but may change it's contents. inetnum: 194.10.0.0 - 194.10.255.255 descr: ALLOCATED BLOCK to LOCAL REGISTRY mnt-by: LOCAL-REGISTRY-MNT mntner: LOCAL-REGISTRY-MNT scope: LOCAL (CREATE & CHANGE & DELETE) scope: LOWER (CREATE & DELETE) Then the registry can register it's customers as follows: inetnum: 194.10.3.0 - 194.10.3.255 descr: CUSTOMER of LOCAL registry The customer may change their object but cannot create/delete it: Discussion: Both proposals solve the problem. Both proposals will have the same implementation complexity. But there of course also some differences: Proposal 1: This solution is probably clearest and easiest to the user by using a special attribute in the objects in the hierarchy itself instead of hiding it in the maintainer object. Of course this is also the weakness: a maintainer object that looks the same may behave differently depending on the context in which it is used. Also, when we introduce the new scheme many objects need an update (this might be an advantage or an disadvantage depending on how you view things...). Furthermore, most objects will again get an extra attribute defined. Proposal 2: The mechanism is hidden for the user and therefore might be less clear. The maintainer object will be the only object that defines authorization policies. We can introduce the mechanism rapidly by just adding an attribute to the maintainer object (In RIPE's case: we only need to add an attribute to our maintainer object to protect the whole RIPE database against unauthorized allocations/assignments in our space). We don't get extra attributes defined for the normal objects. Note that we think that we should choose the best mechanism, even if introducing might be somewhat more complex. The extra workload for proposal one seems not that much more. Expected implementation problems: Implementation for the IP address space notation ranges that are used in 'inetnum' objects will not be trivial due to the internal workings of the database for 'classless' lookups. You probably don't know the details but for the people that are interested: The IP address space ranges are internally converted to prefix notation. When, they don't fit in one prefix, more prefixes are generated. In that case we can get in trouble with overlapping objects that might be found as directly above instead of the correct object. I think it is possible to solve but it will needs some more work then expected at first sight. Please let us know if there exist better solutions or that changes are needed, or just make your choice! David Kessens RIPE NCC