RFC 2769 (rfc2769) - Page 3 of 42

Routing Policy System Replication

RFC 2769           Routing Policy System Replication       February 2000


1  Overview

   A routing registry must maintain some degree of integrity to be of
   any use.  The IRR is increasingly used for purposes that have a
   stronger requirement for data integrity and security.  There is also
   a desire to further decentralize the IRR. This document proposes a
   means of decentralizing the routing registry in a way that is
   consistent with the usage of the IRR and which avoids compromising
   data integrity and security even if the IRR is distributed among less
   trusted repositories.

   Two methods of authenticating the routing registry information have
   been proposed.

   authorization and authentication checks on transactions:  The
      integrity of the routing registry data is insured by repeating
      authorization checks as transactions are processed.  As
      transactions are flooded each remote registry has the option to
      repeat the authorization and authentication checks.  This scales
      with the total number of changes to the registry regardless of how
      many registries exist.  When querying, the integrity of the
      repository must be such that it can be trusted.  If an
      organization is unwilling to trust any of the available
      repositories or mirrors they have the option to run their own
      mirror and repeat authorization checks at that mirror site.
      Queries can then be directed to a mirror under their own
      administration which presumably can be trusted.

   signing routing registry objects:  An alternate which appears on the
      surface to be attractive is signing the objects themselves.
      Closer examination reveals that the approach of signing objects by
      itself is flawed and when used in addition to signing transactions
      and rechecking authorizations as changes are made adds nothing.
      In order for an insertion of critical objects such as inetnums and
      routes to be valid, authorization checks must be made which allow
      the insertion.  The objects on which those authorization checks
      are made may later change.  In order to later repeat the
      authorization checks the state of other objects, possibly in other
      repositories would have to be known.  If the repository were not
      trusted then the change history on the object would have to be
      traced back to the object's insertion.  If the repository were not
      trusted, the change history of any object that was depended upon
      for authorization would also have to be rechecked.  This trace
      back would have to go back to the epoch or at least to a point
      where only trusted objects were being relied upon for the
      authorizations.  If the depth of the search is at all limited,
      authorization could be falsified simply by exceeding the search
      depth with a chain of authorization references back to falsified



Villamizar, et al.          Standards Track