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(a)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)
_____________________________________________________________________________
