RFC 2769 (rfc2769) - Page 3 of 42
Routing Policy System Replication
Alternative Format: Original Text Document
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