again: hierarchical route objects

 Dear all,

 this is quite some discussion (I really did not expect this). Obviously,
 I could have been doing some more thinking before writing my earlier
 mail...

 Now, I try to summarize some of the points. I think Havard made some
 good comments. He really had me reconsider the effect of a "mnt-lower"
 attribute in the aut-num object. Actually, "mnt-lower" makes perfect
 sense if some hierarchically lower object exists (which is valid for
 IP address ranges). From some logical point of view, aut-num objects
 may well be understood as being hierarchically higher than route objects.
 However, to create a route object in the database the current imple-
 mentation already demands a reference to an autnum object and a main-
 tainer object:

route:       [mandatory]  [single]    
descr:       [mandatory]  [multiple]  
origin:      [mandatory]  [single]    
hole:        [optional]   [multiple]  
withdrawn:   [optional]   [single]    
comm-list:   [optional]   [multiple]  
advisory:    [optional]   [multiple]  
remarks:     [optional]   [multiple]  
notify:      [optional]   [multiple]  
mnt-by:      [mandatory]  [multiple]  
changed:     [mandatory]  [multiple]  
source:      [mandatory]  [single]

 By the mandatory mnt-by attribute some authorisation is already needed
 (as specified in the maintainer object). Adding a mnt-lower attribute
 to the *aut-num* object does not change much, and raises the question
 what objects are actually hierarchically below it - these are not
 necessarily route objects. I guess, this is one of the reasons why
 several people feel that a closer relationship to allocated IP address
 space should be established.

 As the mnt-lower attribute in an aut-num object seemingly does not
 lead to additional hierarchical authorisation we arrive at the question
 what we want to achieve with hierarchical authorization of route objects.
 For me the rationale behind it are similar to inetnum objects: to exert
 control. If some origin AS routes an IP range, no other AS shall claim
 this range or subranges. However, we must ask ourselves how reasonable
 this approach is because we run into several problems here (Cengiz,
 Gabor, Steven, and earlier Curtis discussed this):
 - There must be some starting point for the authorization - otherwise
   anybody may create route objects of IP address ranges where none do
   yet exist. This seems to tie the route objects closely to allocated
   address space (which again leads to problems - as noted before - be-
   cause several registries are pure routing registries). Moreover,
   route objects may be created in one registry which are forbidden by
   authorisation in another. This really calls for "the GRR" (where
   pure routing registries might be regarded as less authoritative).
   I fear we do not have a solution for this problem today.
 - Multihoming will be impossible if authorization is based upon IP
   address ranges alone because in this case only one route object
   of one origin is allowed in the registry for each IP range.
 - Situations may arise where IP subranges must be routed by another AS
   than specified in an less specific route object. To restrict access
   to these subranges the "hole" attribute might be applicable. Subranges
   defined by "hole" could be excluded from the authorization as long as
   no route object exists which covers this subrange. I can imagine that
   this is complicated regarding implementation in the database software.
 - Handing over route objects from one maintainer to another will become
   difficult - up to now this is solved by allowing existence of several
   route objects for the same address space but of differing origin. This
   is a very convenient solution thinking of cases where filters for
   router configurations are built from route objects in the database.
   If two identical route objects of different origin exist this may
   allow a smooth switch over from one AS to another. With an authorisation
   scheme solely based upon IP address ranges as specified above this would
   no longer be possible.
 - Others?
 While with inetnum-objects the "mnt-lower" attribute leads to strong
 control there was a suggestion by Daniel that for route objects noti-
 fication may be sufficient. On the one hand (taking it to the extremes)
 this might lead to cases where an organisation controls an inetnum
 object but others control the route objects of the same address range
 (this may be reasonable but also a real competitive problem). On the
 other hand is this restriction needed because then at least multi-
 homing will probably become impossible? Anyway: obviously, checking
 hierarchical authorization with route objects is quite complex regard-
 less of the fact whether notification only or restrictive authorization
 is applied.

 This whole thing became longer than I first intended. It seems there
 is more in it than we all thought first ... however, some of the problems
 we have run into look similar to those of inetnum objects ... may I ask
 for additional comments? Any further suggestions, problems,... ?

 Regards
    Joachim
_____________________________________________________________________________

 Dr. Joachim Schmitz                                   schmitz at 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)
_____________________________________________________________________________