Hierarchical authorization proposal

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