Hierarchical Authorisation for Route Objects

Current state and open issues

Joachim Schmitz RIPE 26 / 20. Jan. 97

This paper comprises the discussion on the mailing list as it was just before the RIPE 26 meeting. For newer details refer to the RIPE webserver or the mail archive of the Routing Working Group.

Current state
Need for hierarchical authorisation
Relation to the aut-num-object
Relation to inetnum-objects
Prefix based hierarchical scheme
A temporary suggestion

Relation to the `aut-num`-object

AS number constitutes routing entity
However, mnt-lower tag not applicable in current implementation of aut-num-object

                                            +-------------------------+
                               ,---> ,--->  | mntner:  ASx-MNT        |
                               |     |      | descr:   maintainer ASx |
                               |     |      | ...                     |
                               |     |      | auth:    CRYPT-PW ...   |
                               |     |      | ...                     |
  +--------------------+       |     |      +-------------------------+
  | aut-num:  ASx      |       |     |
  | descr:    Mister x |       |     |
  | ...                |       |     |
  | mnt-by:   ASx-MNT  |  -----'     |
  +--------------------+             |      +-------------------------+
            ^                        |      | route:   x.y.0.0/16     |
            |                        |      | descr:   my route       |
            |                        `----  | mnt-by:  ASx-MNT        |
            `-----------------------------  | origin:  ASx            |
                                            | ...                     |
                                            +-------------------------+

Relation to `inetnum`-objects

Make route-objects dependent on inetnum-objects?

no routes without allocation!
not applicable for pure routing registries

Combine address space ownership and route-objects?

already done by maintainer
not applicable for pure routing registries
ownership and routing often differ
change in routing may demand change in inetnum-object

Relationship is difficult, problems might be solved in a unified distributed global registry, but not now.

Prefix based hierarchical scheme

Apply same prefix based hierarchical scheme as for inetnum-objects?

working mechanism
starting point = top level route-objects
- artifical objects (no routing)
- the swamp 192.x
only one route-object per IP-range
- multihoming (multiple origins?)
- allow other origin for IP-subranges (holes?)
- transition from one AS to another (multiple maintainers?)
object in one registry is not secured by hierarchical authorisation in another
duplication in several RRs

Enforcement of prefix based hierarchical authorisation causes troubles

A temporary suggestion

Apply prefix based hierarchical scheme but do not enforce it, just notify

working mechanism
nothing much changes
starting point not compulsory
duplication in several RRs without consequences
several route-objects of differing origin per IP-range
object in one registry is not secured by hierarchical authorisation in another
no real solution

Slight improvement to the current situation, upwards compatible because notification is also needed if authorisation is enforced.

When to notify?

Some suggestions by D. Karrenberg for notification in a prefix based hierarchical scheme

only notify if requested by an object hierarchically higher
- or -
always notify for overlapping routes?
notification only triggered by other route-objects
- or -
also by inetnum-objects of overlapping address space?
notify creator of route-objects of notifications for coordination purposes?

How to proceed from here?