RFC 2725 (rfc2725) - Page 3 of 41
Routing Policy System Security
Alternative Format: Original Text Document
RFC 2725 Routing Policy System Security December 1999
1 Overview
The Internet Routing Registry (IRR) has evolved to meet a need for
Internet-wide coordination. This need was described in RFC-1787, an
informational RFC prepared on behalf of the IAB [14]. The following
summary appears in Section 7 of RFC-1787.
While ensuring Internet-wide coordination may be more and more
difficult, as the Internet continues to grow, stability and
consistency of the Internet-wide routing could significantly
benefit if the information about routing requirements of various
organizations could be shared across organizational boundaries.
Such information could be used in a wide variety of situations
ranging from troubleshooting to detecting and eliminating
conflicting routing requirements. The scale of the Internet
implies that the information should be distributed. Work is
currently underway to establish depositories of this information
(Routing Registries), as well as to develop tools that analyze, as
well as utilize this information.
A routing registry must maintain some degree of integrity to be of
any use. The degree of integrity required depends on the usage of
the routing policy system.
An initial intended usage of routing policy systems such as the RIPE
database had been in an advisory capacity, documenting the intended
routing policies for the purpose of debugging. In this role a very
weak form of authentication was deemed sufficient.
The IRR is increasingly used for purposes that have a stronger
requirement for data integrity and security. This document addresses
issues of data integrity and security 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.
2 Background
An early routing policy system used in the NSFNET, the policy routing
database (PRDB), provided a means of determining who was authorized
to announce specific prefixes to the NSFNET backbone. The need for a
policy database was recognized as far back as 1989 [6, 4]. By 1991
the database was in place [5]. Authentication was accomplished by
requiring confirmation and was a manually intensive process. This
solved the problem for the NSFNET, but was oriented toward holding
the routing policy of a single organization.
Villamizar, et al. Standards Track