doc: Add RFC documents

1 files changed, 2299 insertions, 0 deletions

diff --git a/doc/rfc/rfc2725.txt b/doc/rfc/rfc2725.txt
new file mode 100644
index 0000000..fe952f2
--- /dev/null
+++ b/doc/rfc/rfc2725.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+Network Working Group                                      C. Villamizar
+Request for Comments: 2725                                         Avici
+Category: Standards Track                                C. Alaettinoglu
+                                                                     ISI
+                                                                D. Meyer
+                                                                   Cisco
+                                                               S. Murphy
+                                                                     TIS
+                                                           December 1999
+
+
+                     Routing Policy System Security
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The RIPE database specifications and RPSL language define languages
+   used as the basis for representing information in a routing policy
+   system.  A repository for routing policy system information is known
+   as a routing registry.  A routing registry provides a means of
+   exchanging information needed to address many issues of importance to
+   the operation of the Internet.  The implementation and deployment of
+   a routing policy system must maintain some degree of integrity to be
+   of any operational use.  This document addresses the need to assure
+   integrity of the data by providing an authentication and
+   authorization model.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                     [Page 1]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+Table of Contents
+
+   1  Overview  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2  Background  . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3  Implicit Policy Assumptions . . . . . . . . . . . . . . . .  5
+   4  Scope of Security Coverage  . . . . . . . . . . . . . . . .  5
+   5  Organization of this Document   . . . . . . . . . . . . . .  6
+   6  Goals and Requirements  . . . . . . . . . . . . . . . . . .  6
+   7  Data Representation . . . . . . . . . . . . . . . . . . . . 10
+   8  Authentication Model  . . . . . . . . . . . . . . . . . . . 10
+   9  Authorization Model . . . . . . . . . . . . . . . . . . . . 12
+     9.1   Maintainer Objects . . . . . . . . . . . . . . . . . . 12
+     9.2   as-block and aut-num objects . . . . . . . . . . . . . 13
+     9.3   inetnum objects  . . . . . . . . . . . . . . . . . . . 13
+     9.4   route objects  . . . . . . . . . . . . . . . . . . . . 14
+     9.5   reclaim and no-reclaim attributes  . . . . . . . . . . 14
+     9.6   Other Objects  . . . . . . . . . . . . . . . . . . . . 15
+     9.7   Objects with AS Hierarchical Names . . . . . . . . . . 16
+     9.8   Query Processing . . . . . . . . . . . . . . . . . . . 16
+     9.9   Adding to the Database . . . . . . . . . . . . . . . . 17
+     9.10  Modifying or Deleting Database Objects . . . . . . . . 19
+   10  Data Format Summaries  . . . . . . . . . . . . . . . . . . 20
+     10.1  Changes to the RIPE/RPSL Schema  . . . . . . . . . . . 20
+   Appendicies
+   A  Core and Non-Core Functionality . . . . . . . . . . . . . . 23
+   B  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . 23
+   C  Technical Discussion  . . . . . . . . . . . . . . . . . . . 26
+     C.1   Relaxing requirements for ease of registry   . . . . . 27
+     C.2   The address lending issue  . . . . . . . . . . . . . . 28
+     C.3   Dealing with non-conformant or questionable older
+           data . . . . . . . . . . . . . . . . . . . . . . . . . 29
+   D  Common Operational Cases  . . . . . . . . . . . . . . . . . 30
+     D.1   simple hierarchical address allocation and route
+           allocation . . . . . . . . . . . . . . . . . . . . . . 31
+     D.2   aggregation and multihomed more specific routes  . . . 32
+     D.3   provider independent addresses and multiple origin
+           AS . . . . . . . . . . . . . . . . . . . . . . . . . . 32
+     D.4   change in Internet service provider  . . . . . . . . . 32
+     D.5   renumbering grace periods  . . . . . . . . . . . . . . 32
+   E  Deployment Considerations . . . . . . . . . . . . . . . . . 33
+   F  Route Object Authorization Pseudocode . . . . . . . . . . . 35
+   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 37
+   Intellectual Property Notice . . . . . . . . . . . . . . . . . 38
+   References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
+   Security Considerations  . . . . . . . . . . . . . . . . . . . 40
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
+   Full Copyright Statement   . . . . . . . . . . . . . . . . . . 41
+
+
+
+
+Villamizar, et al.          Standards Track                     [Page 2]
+
+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                     [Page 3]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   The problem since has become more difficult.  New requirements have
+   emerged.
+
+   1. There is a need to represent the routing policies of many
+      organizations.
+
+   2. CIDR and overlapping prefixes and the increasing complexity of
+      routing policies and the needs of aggregation have introduced new
+      requirements.
+
+   3. There is a need to assure integrity of the data and delegate
+      authority for the data representing specifically allocated
+      resources to multiple persons or organizations.
+
+   4. There is a need to assure integrity of the data and distribute the
+      storage of data subsets to multiple repositories.
+
+   The RIPE effort specificly focused on the first issue and needs of
+   the European community.  Its predecessor, the PRDB, addressed the
+   needs of a single organization, the NSF. The RIPE database formats as
+   described in [2] were the basis of the original IRR.
+
+   Routing protocols themselves provide no assurance that the
+   origination of a route is legitimate and can actually reach the
+   stated destination.  The nature of CIDR allows more specific prefixes
+   to override less specific prefixes [9, 15, 8].  Even with signed
+   route origination, there is no way to determine if a more specific
+   prefix is legitimate and should override a less specific route
+   announcement without a means of determining who is authorized to
+   announce specific prefixes.  Failing to do so places no assurance of
+   integrity of global routing information and leaves an opportunity for
+   a very effective form of denial of service attack.
+
+   The Routing Policy System Language (RPSL) [1, 13] was a fairly
+   substantial evolutionary step in the data representation which was
+   largely targeted at addressing the second group of needs.  The PRDB
+   accommodated CIDR in 1993 [12] and the RIPE database accommodated the
+   entry of CIDR prefixes from inception, but RPSL provides many needed
+   improvements including explicit support for aggregation.
+
+   This document addresses the third group of needs identified above.
+
+   While the current implementation supporting weak authentication
+   doesn't guarantee integrity of the data, it does provide extensive
+   mechanisms to make sure that all involved parties get notified when a
+   change is made to the database, whether the change was malicious or
+   intended.  This provides inadequate protection against additions.
+   Since the software is increasingly used to configure the major parts
+
+
+
+Villamizar, et al.          Standards Track                     [Page 4]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   of the Internet infrastructure, it is not considered to be adequate
+   anymore to know about and have the ability roll back unintended
+   changes.  Therefore, more active security mechanisms need to be
+   developed to prevent such problems before they happen.
+
+   A separate document will be needed to address the fourth group of
+   needs.
+
+3  Implicit Policy Assumptions
+
+   The authorization model encodes certain policies for allocation of
+   address numbers, AS numbers, and for the announcement of routes.
+   Implicit to the authorization model is a very limited number of
+   policy assumptions.
+
+   1. Address numbers are allocated hierarchically.  The IANA delegates
+      portions of the address space to the regional registries
+      (currently ARIN, APNIC and RIPE), which in turn delegate address
+      space to their members, who can assign addresses to their
+      customers.
+
+   2. AS numbers are allocated either singly or in small blocks by
+      registries.  Registries are allocated blocks of AS numbers,
+      thereby making the allocation hierarchical.
+
+   3. Routes should only be announced with the consent of the holder of
+      the origin AS number of the announcement and with the consent of
+      the holder of the address space.
+
+   4. AS numbers and IP address registries may be different entities
+      from routing registries.
+
+   For subsets of any of these three allocation spaces, network
+   addresses, AS numbers, and routes, these restrictions may be loosened
+   or disabled by specifying a very weak authorization method or an
+   authentication method of "none".  However, even when no
+   authentication mechanism is used, all involved parties can be
+   notified about the changes that occurred through use of the existing
+   "notify" attribute.
+
+4  Scope of Security Coverage
+
+   This document is intended only to provide an authentication and
+   authorization model to insure the integrity of the policy data in a
+   registry.  Only authetication and authorization of additions,
+   deletions, and changes to the database are within the scope of this
+   document.  Authentication and authorization of database queries is
+
+
+
+
+Villamizar, et al.          Standards Track                     [Page 5]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   explicitly out of scope.  Mutual authentication of queries, that is
+   authenticating both the origin of the query and the repository from
+   which query results are obtained, is also out of scope.
+
+5  Organization of this Document
+
+   Familiarity with RIPE-181 [2] and RPSL [1] is assumed throughout this
+   document.  Goals are described in Section 6.  Section 7 through
+   Section 9 provide descriptions of the changes and discussion.
+   Section 10 provides a concise summary of data formats and semantics.
+   Appendix C through Appendix E provide additional technical
+   discussion, examples, and deployment considerations.
+
+      Goals and Requirements Section 6 provides a more detailed
+      description of the issues and identifies specific problems that
+      need to be solved, some of which require a degree of cooperation
+      in the Internet community.
+
+      Data Representation Section 7 provides some characteristics of
+      RPSL and formats for external representations of information.
+
+      Authentication Model Section 8 describes current practice,
+      proposes additional authentication methods, and describes the
+      extension mechanism if additional methods are needed in the
+      future.
+
+      Authorization Model Section 9 describes the means of determining
+      whether a transaction contains the authorization needed to add,
+      modify, or delete specific data objects, based on stated
+      authentication requirements in related data objects.
+
+      Data Format Summaries Section 10 provides a concise reference to
+      the data formats and steps in transaction processing.
+
+      Technical Discussion Section C contains some discussion of
+      technical tradeoffs.
+
+      Common Operational Cases Section D provides some examples drawn
+      from past operational experience with the IRR.
+
+      Deployment Considerations Section E describes some deployment
+      issues and discusses possible means of resolution.
+
+6  Goals and Requirements
+
+   The Internet is an open network.  This openness and the large scale
+   of the Internet can present operational problems.  Technical
+   weaknesses that allow misconfiguration or errant operation in part of
+
+
+
+Villamizar, et al.          Standards Track                     [Page 6]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   the network to propagate globally or which provide potentials for
+   simple denial of service attacks should be eliminated to the extent
+   that it is practical.  The integrity of routing information is
+   critical in assuring that traffic goes where it is supposed to.
+
+   An accidental misconfiguration can direct traffic toward routers that
+   cannot reach a destination for which they are advertising
+   reachability.  This is commonly caused by misconfigured static routes
+   though there are numerous other potential causes.  Static routes are
+   often used to provide constant apparent reachability to single homed
+   destinations.  Some of the largest ISPs literally have thousands of
+   static routes in their networks.  These are often entered manually by
+   operators.  Mistyping can divert traffic from a completely unrelated
+   destination to a router with no actual reachability to the advertised
+   destination.  This can happen and does happen somewhat regularly.  In
+   addition, implementation bugs or severe misconfigurations that result
+   in the loss of BGP AS path information or alteration of prefix length
+   can result in the advertisement of large sets of routes.  Though
+   considerably more rare, on a few occasions where this has occurred
+   the results were catastrophic.
+
+   Where there is the potential for an accidental misconfiguration in a
+   remote part of the Internet affecting the global Internet there is
+   also the potential for malice.  For example, it has been demonstrated
+   by accident that multiple hour outages at a major institution can be
+   caused by a laptop and a dial account if proper precautions are not
+   taken.  The dial account need not be with the same provider used by
+   the major institution.
+
+   The potential for error is increased by the CIDR preference for more
+   specific routes [8].  If an institution advertises a single route of
+   a given length and a distant router advertises a more specific route
+   covering critical hosts, the more specific route, if accepted at all,
+   is preferred regardless of administrative weighting or any routing
+   protocol attributes.
+
+   There is a need to provide some form of checks on whether a route
+   advertisement is valid.  Today checks are typically made against the
+   border AS advertising the route.  This prevents accepting routes from
+   the set of border AS that could not legitimately advertise the route.
+   Theses checks rely on the use of information registered in the IRR to
+   generate lists of prefixes that could be advertised by a specific
+   border AS. Checks can also be made against the origin AS. If policy
+   information were sufficiently populated, checks could be made against
+   the entire AS path, but this is not yet feasible.
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                     [Page 7]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   The use of a routing registry can also make it more difficult for
+   prefixes to be used without authorization such as unallocated
+   prefixes or prefixes allocated to another party.
+
+   In summary, some of the problems being addressed are:
+
+   o  Localizing the impact of accidental misconfiguration made by
+      Internet Providers to that provider's networks only.
+
+   o  Eliminating the potential for an Internet provider's customer to
+      use malicious misconfiguration of routing as a denial of service
+      attack if the provider route filters their customers.  Localizing
+      the denial of service to that Internet provider only if the
+      immediate Internet service provider does not route filter their
+      customers but other providers route filter the route exchange at
+      the interprovider peering.
+
+   o  Eliminating the unauthorized use of address space.
+
+   If the data within a routing registry is critical, then the ability
+   to change the data must be controlled.  Centralized authorities can
+   provide control but centralization can lead to scaling problems (and
+   is politically distasteful).
+
+   Address allocation and name allocation is already delegated.  Since
+   delegation can be to outside registries it is at least somewhat
+   distributed [11].  Autonomous System (AS) numbers are allocated by
+   the same authorities.  It makes sense to delegate the routing number
+   space in a manner similar to the address allocation and AS number
+   allocation.  The need for this delegation of authority to numerous
+   registries increases the difficulty of maintaining the integrity of
+   the body of information as a whole.
+
+   As a first step, the database can be somewhat centrally administered
+   with authority granted to many parties to change the information.
+   This is the case with the current IRR. There are a very small number
+   of well trusted repositories and a very large number of parties
+   authorized to make changes.  Control must be exercised over who can
+   make changes and what changes they can make.  The distinction of who
+   vs what separates authentication from authorization.
+
+   o  Authentication is the means to determine who is attempting to make
+      a change.
+
+   o  Authorization is the determination of whether a transaction
+      passing a specific authentication check is allowed to perform a
+      given operation.
+
+
+
+
+Villamizar, et al.          Standards Track                     [Page 8]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   Different portions of the database will require different methods of
+   authentication.  Some applications will require authentication based
+   on strong encryption.  In other cases software supporting strong
+   encryption may not be necessary or may not be legally available.  For
+   this reason multiple authentication methods must be supported,
+   selected on a per object basis through the specification of
+   authentication methods in the maintainer object "auth" attribute.
+   The authentication methods may range from very weak data integrity
+   checks to cryptographicly strong signatures.  The authorization model
+   must sure that the use of weak integrity checks in parts of the
+   database does not compromise the overall integrity of the database.
+
+   Additional requirements are placed on the authorization model if the
+   database is widely distributed with delegations made to parties that
+   may not be trustworthy or whose security practices may be lacking.
+   This problem must be addressed in the authorization model in order to
+   enable later evolution to a more distributed routing registry.
+
+   Autonomous system numbers can be delegated in blocks and subdelegated
+   as needed and then individual AS numbers assigned.  Address
+   allocation is a simple numeric hierarchy.  Route allocation is
+   somewhat more complicated.  The key attributes in a route object (key
+   with regard to making it unique) contain both an address prefix and
+   an AS number, known as the origin AS. The addition of a route object
+   must be validated against the authorization criteria for both the AS
+   and the address prefix.  Route objects may exist for the same prefix
+   with multiple origin AS values due to a common multihoming practice
+   that does not require a unique origin AS. There is often no
+   correlation between the origin AS of a prefix and the origin AS of
+   overlapping more specific prefixes.
+
+   There are numerous operational cases that must be accommodated.  Some
+   of the more common are listed below.  These are explored in greater
+   detail in Appendix D with discussion of technical tradeoffs in
+   Appendix C.
+
+   o  simple hierarchical address allocation and route allocation
+
+   o  aggregation and multihomed more specific routes
+
+   o  provider independent addresses and multiple origin AS
+
+   o  changing Internet service providers
+
+   o  renumbering grace periods
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                     [Page 9]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   The authorization model must accommodate a variety of policies
+   regarding the allocation of address space and cannot mandate the use
+   of any one model.  There is no standardization of address allocation
+   policies though guidelines do exist [11, 16].  Whether authorization
+   allows the recovery of address space must be selectable on a per
+   object basis and may differ in parts of the database.  This issue is
+   discussed further in Appendix C.
+
+7  Data Representation
+
+   RPSL provides a complete description of the contents of a routing
+   repository [1].  Many RPSL data objects remain unchanged from the
+   RIPE specifications and RPSL references the RIPE-181 specification as
+   recorded in RFC-1786 [2].  RPSL provides external data
+   representation.  Data may be stored differently internal to a routing
+   registry.
+
+   Some database object types or database attributes must be added to
+   RPSL to record the delegation of authority and to improve the
+   authentication and authorization mechanisms.  These additions are
+   very few and are described in Section 8 and Section 9.
+
+   Some form of encapsulation must be used to exchange data.  The
+   defacto encapsulation has been the one which the RIPE tools accept, a
+   plain text file or plain text in the body of an RFC-822 formatted
+   mail message with information needed for authentication derived from
+   the mail headers or the body of the message.  Merit has slightly
+   modified this using the PGP signed portion of a plain text file or
+   PGP signed portion of the body of a mail message.  These very simple
+   forms of encapsulation are suitable for the initial submission of a
+   database transaction.
+
+   The encapsulation of registry transaction submissions, registry
+   queries and registry responses and exchanges between registries is
+   outside the scope of this document.  The encapsulation of registry
+   transaction submissions and exchanges between registries is outside
+   the scope of this document.
+
+8  Authentication Model
+
+   The maintainer objects serve as a container to hold authentication
+   filters.  A reference to a maintainer within another object defines
+   authorization to perform operations on the object or on a set of
+   related objects.  The maintainer is typically referenced by name in
+   mnt-by attributes of objects.  Further details on the use of
+   maintainers are provided in Section 9.1.
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 10]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   The maintainer contains one or more "auth" attributes.  Each "auth"
+   attribute begins with a keyword identifying the authentication method
+   followed by the authentication information needed to enforce that
+   method.  The PGPKEY method is slightly syntactically different in
+   that the method PGPKEY is a substring.
+
+   Authentication methods currently supported include the following.
+   Note that pgp-from is being replaced by the pgpkey (see Section 10
+   and [18]).
+
+   mail-from  This is a very weak authentication check and is
+      discouraged.  The authentication information is a regular
+      expression over ASCII characters.  The maintainer is authenticated
+      if the from or reply-to fields in RFC-822 mail headers are matched
+      by this regular expression.  Since mail forgery is quite easy,
+      this is a very weak form of authentication.
+
+   crypt-pw  This is another weak form of authentication.  The
+      authentication information is a fixed encrypted password in UNIX
+      crypt format.  The maintainer is authenticated if the transaction
+      contains the clear text password of the maintainer.  Since the
+      password is in clear text in transactions, it can be captured by
+      snooping.  Since the encrypted form of the password is exposed, it
+      is subject to password guessing attacks.
+
+   pgp-from  This format is being replaced by the "pgpkey" so that the
+      public key certificate will be available to remote repositories.
+      This is Merit's PGP extension.  The authentication information is
+      a signature identity pointing to an external public key ring.  The
+      maintainer is authenticated if the transaction (currently PGP
+      signed portion of a mail message) is signed by the corresponding
+      private key.
+
+   pgpkey  This keyword takes the form "PGPKEY-hhhhhhhh", where
+      "hhhhhhhh" is the hex representation of the four byte id of the
+      PGP public key used for authentication.  The public key
+      certificate is stored in a separate object as described in [18].
+
+   Repositories may elect to disallow the addition of "auth" attributes
+   specifying weaker forms of authentication and/or disallow their use
+   in local transaction submissions.  Repositories are encouraged to
+   disallow the addition of "auth" attributes with the deprecated "pgp-
+   from" method.
+
+   Any digital signature technique can in principle be used for
+   authentication.  Transactions should be signed using multiple digital
+   signature techniques to allow repositories or mirrors that only use a
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 11]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   subset of the techniques to verify at least one of the signatures.
+   The selection of digital signature techniques is not within the scope
+   of this document.
+
+9  Authorization Model
+
+   The authorization model must accommodate the requirements outlined in
+   Section 6.  A key feature of the authorization model is the
+   recognition that authorization for the addition of certain types of
+   data objects must be derived from related data objects.
+
+   With multiple repositories, objects not found in RPSL are needed to
+   control AS delegations and new attributes are needed in existing
+   objects to control subdelegation.  The definition of RPSL objects
+   used to implement a distrubuted routing registry system is not within
+   the scope of this document.
+
+9.1  Maintainer Objects
+
+   The maintainer objects serve as a container to hold authentication
+   filters.  The authentication methods are described in Section 8.  The
+   maintainer can be referenced by name in other objects, most notably
+   in the mnt-by attributes of those objects.
+
+   Maintainers themselves contain mnt-by attributes.  In some cases the
+   mnt-by in a maintainer will reference the maintainer itself.  In this
+   case, authorization to modify the maintainer is provided to a
+   (usually very limited) set of identities.  A good practice is to
+   create a maintainer containing a long list of identities authorized
+   to make specific types of changes but have the maintainer's mnt-by
+   attribute reference a far more restrictive maintainer more tightly
+   controlling changes to the maintainer object itself.
+
+   The mnt-by attribute is mandatory in all objects.  Some data already
+   exists without mnt-by attributes.  A missing mnt-by attribute is
+   interpreted as the absence of any control over changes.  This is
+   highly inadvisable and most repositories will no longer allow this.
+
+   An additional maintainer reference can occur through a new attribute,
+   "mnt-routes", and is used in aut-num, inetnum and route objects.  The
+   "mnt-routes" attribute is an extension to RPSL and is described in
+   detail in Section 10.
+
+   A mnt-routes attribute in an aut-num object allows addition of route
+   objects with that AS number as the origin to the maintainers listed.
+   A mnt-routes attribute in an inetnum object allows addition of route
+   objects with exact matching or more specific prefixes.  A mnt-routes
+   attribute in a route object allows addition of route objects with
+
+
+
+Villamizar, et al.          Standards Track                    [Page 12]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   exact matching or more specific prefixes.  A mnt-routes attribute
+   does not allow changes to the aut-num, inetnum, or route object where
+   it appears.  A mnt-routes may optionally be constrained to only apply
+   to a subset of more specific routes.
+
+   Where "mnt-routes" or "mnt-lower" are applicable, any maintainer
+   referenced in the "mnt-by" still apply.  The set of applicable
+   maintainers for whatever check is being made is the union of the
+   "mnt-routes" or "mnt-lower" and the "mnt-by".  For example, when
+   authorizing a route object software would look at "mnt-routes", if it
+   does not exist, look at "mnt-lower", if that does not exist look at
+   "mnt-by".
+
+9.2  as-block and aut-num objects
+
+   An "as-block" object is needed to delegate a range of AS numbers to a
+   given repository.  This is needed for authorization and it is needed
+   to avoid having to make an exhaustive search of all repositories to
+   find a specific AS. This search would not be an issue now but would
+   be if a more distributed routing repository is used.  Distributed
+   registry issues are not within the scope of this document.
+
+   The "as-block" object also makes it possible to separate AS number
+   allocation from registration of AS routing policy.
+
+      as-block:        AS1321 - AS1335
+
+   The "aut-num" describes the routing policy for an AS and is critical
+   for router configuration of that AS and for analysis performed by
+   another AS. For the purpose of this document it is sufficient to
+   consider the aut-num solely as a place holder identifying the
+   existence of an AS and providing a means to associate authorization
+   with that AS when adding "route" objects.
+
+   The "as-block" object is proposed here solely as a means of recording
+   the delegation of blocks of AS numbers to alternate registries and in
+   doing so providing a means to direct queries and a means to support
+   hierarchical authorization across multiple repositories.
+
+9.3  inetnum objects
+
+   The "inetnum" exists to support address allocation.  For external
+   number registries, such as those using "[r]whoisd[++]" the "inet-num"
+   can serve as a secondary record that is added when an address
+   allocation is made in the authoritative database.  Such records could
+   be added by a address registry such as ARIN as a courtesy to the
+   corresponding routing registry.
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 13]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+      inetnum:        193.0.0.0 - 193.0.0.255
+      source:         IANA
+
+9.4  route objects
+
+   Currently there are a quite few route objects in more than one
+   registry.  Quite a few are registered with an origin AS for which
+   they have never been announced.  There is a legitimate reason to be
+   in more than one origin AS.
+
+   The "route" object is used to record routes which may appear in the
+   global routing table.  Explicit support for aggregation is provided.
+   Route objects exist both for the configuration of routing information
+   filters used to isolate incidents of erroneous route announcements
+   (Section 6) and to support network problem diagnosis.
+
+9.5  reclaim and no-reclaim attributes
+
+   A reclaim attribute is needed in as-block, inetnum and route objects.
+   The reclaim attribute allows a control to be retained over more
+   specific AS, IP address or route space by allowing modify and delete
+   privileges regardless of the mnt-by in the object itself.
+
+   The reclaim attribute provides the means to enforce address lending.
+   It allows cleanup in cases where entities cease to exist or as a last
+   presort means to correct errors such as parties locking themselves
+   out of access to their own objects.  To specify all more specific
+   objects the reclaim attribute value should be "ALL". To allow finer
+   control a set of prefixes can be specified.
+
+   A no-reclaim attribute can be used to provide explicit exceptions.  A
+   reclaim attribute can only be added to an existing object if the
+   addition of the reclaim attribute does not remove autonomy of
+   existing more specific objects that are covered by the new reclaim
+   attribute.
+
+   1. A reclaim attribute can be added to an existing object if there
+      are no existing exact matches or more specific objects overlapped
+      by the new reclaim attribute, or
+
+   2. if the submitter is listed in the maintainer pointed to by the
+      mnt-by of the objects which are overlapped, or
+
+   3. if any overlapped object is listed in a no-reclaim attribute in
+      the object where the reclaim is being added.
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 14]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   Similarly, a submitter may delete a no-reclaim attribute from an
+   object only when that submitter is the only maintainer listed in the
+   mnt-by attributes of any overlapped objects.  If the submitter is not
+   listed in any of the maintainers pointed to by the mnt-by attributes
+   for one or more overlapped object, then the submitter is not
+   permitted to delete the no-reclaim attribute.
+
+   If neither a reclaim or no-reclaim attribute is present, then more
+   specific objects of a given object cannot be modified by the
+   maintainer of the less specified object unless the maintainer is also
+   listed as a maintainer in the more specific object.  However, the
+   addition of a new route or inetnum object must pass authentication of
+   the largest less specific prefix as part of the authentication check
+   described in Section 9.9.
+
+   See Section 10 for a full description of the reclaim and no-reclaim
+   attributes.
+
+9.6  Other Objects
+
+   Many of the RPSL ancillary objects have no natural hierarchy the way
+   AS numbers, Internet addresses and routes do have a numeric
+   hierarchy.  Some examples are "maintainers", "people" and "role"
+   objects.  For these objects, lack of any hierarchy leads to two
+   problems.
+
+   1. There is no hierarchy that can be exploited to direct queries to
+      alternate registries.  At some point the query strategy of
+      searching all known registries becomes impractical.
+
+   2. There is no hierarchy on which authorizations of additions can be
+      based.
+
+   The first problem can be addressed by considering the name space for
+   each of the ancillary objects to be unique only within the local
+   database and to use explicit references to an external repository
+   where needed.  To specify an external repository reference, the
+   object key is preceded by the name of the repository and the
+   delimiter "::".  For example a NIC handle may take the form
+   "RIPE::CO19".  Currently there is a desire to keep NIC handles unique
+   so the naming convention of appending a dash and the repository name
+   is used.  Prepending the repository name provides the unique name
+   space since an object in the RIPE database referencing "CO19" would
+   be interpreted as "RIPE::CO19" by default, but it would still be
+   possible to query or reference "IANA::CO19".  There is no possibility
+   of accidentally forgetting to adhere to the conventions when making
+   an addition and the existing objects are accommodated, including
+   cases where name conflicts have already occurred.
+
+
+
+Villamizar, et al.          Standards Track                    [Page 15]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   The second problem can be partially addressed by using a referral
+   system for the addition of maintainers and requiring that any other
+   object be submitted by a registered maintainer or by IANA.  The
+   referral system would allow any existing maintainer to add another
+   maintainer.  This can be used in parallel with the addition of other
+   object types to support the maintenance of those objects.  For
+   example, when adding a subdomain to the "domain" hierarchy (in the
+   RIPE repository where domains are also handled), even when adding a
+   new domain to a relatively flat domain such as "com", there is
+   already a maintainer for the existing domain.  The existing
+   maintainer can add the maintainer that will be needed for the new
+   domain in addition to adding the new domain and giving the new
+   maintainer the right to modify it.
+
+   An organization gaining a presence on the Internet for the first time
+   would be given a maintainer.  This maintainer may list a small number
+   of very trusted employees that are authorized to modify the
+   maintainer itself.  The organization itself can then add another
+   maintainer listing a larger set of employees but listing the more
+   restrictive maintainer in the mnt-by attributes of the maintainers
+   themselves.  The organization can then add people and role objects as
+   needed and any other objects as needed and as authorization permits.
+
+9.7  Objects with AS Hierarchical Names
+
+   Many RPSL objects do not have a natural hierarchy of their own but
+   allow hierarchical names.  Some examples are the object types "as-
+   set" and "route-set".  An as-set may have a name corresponding to no
+   naming hierarchy such as "AS-Foo" or it may have a hierarchical name
+   of the form "AS1:AS-Bar".
+
+   When a hierarchical name is not used, authorization for objects such
+   as "as-set" and "route-set" correspond to the rules for objects with
+   no hierarchy described in Section 9.6.
+
+   If hierarchical names are used, then the addition of an object must
+   be authorized by the aut-num whose key is named by everything to the
+   left of the rightmost colon in the name of the object being added.
+   Authorization is determined by first using the mnt-lower maintainer
+   reference, or if absent, using the mnt-by reference.
+
+9.8  Query Processing
+
+   A query may have to span multiple repositories.  All queries should
+   be directed toward a local repository which may mirror the root
+   repository and others.  Currently each IRR repository mirrors all
+   other repositories.  In this way, the query may be answered by the
+   local repository but draw data from others.
+
+
+
+Villamizar, et al.          Standards Track                    [Page 16]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   The mechanism below when applied to multiple repositories assumes the
+   existence of an attribute for traversal of the repositories.  The
+   definition of this attribute is considered a distributed registry
+   issue and is out of scope of this document.
+
+   For object types that have a natural hierarchy, such as aut-num,
+   inet-num, and route, the search begins at the root database and
+   follows the hierarchy.  For objects types that have no natural
+   hierarchy, such as maintainer, person, and role objects, the search
+   is confined to a default database unless a database is specified.
+   The default database is the same database as an object from which a
+   reference is made if the query is launched through the need to follow
+   a reference. Otherwise the default is generally the local database or
+   a default set by the repository.  The default can be specified in the
+   query itself as described in Section 9.7.
+
+   In the absense of attributes to traverse multiple registries a search
+   of all repositories is needed.  With such attributes the search would
+   proceed as follows.  In searching for an AS, the delegation attribute
+   in AS blocks can be consulted, moving the search to data from other
+   repositories.  Eventually the AS is either found or the search fails.
+   The search for an inetnum is similar.  Less specific inetnums may
+   refer the search to other databases.  Eventually the most specific
+   inetnum is found and its status (assigned or not assigned) can be
+   determined.  The definition of attributes for traversal of
+   repositories is considered a distrbiuted registry issue and is not
+   within the scope of this document.
+
+   The search for a route in the presence of attributes for the
+   traversal of multiple registries is similar except the search may
+   branch to more than one repository.  The most specific route in one
+   repository may be more specific than the most specific in another.
+   In looking for a route object it makes sense to return the most
+   specific route that is not more specific than the query requests
+   regardless of which repository that route is in rather than return
+   one route from each repository that contains a less specific overlap.
+
+9.9  Adding to the Database
+
+   The mechanism below when applied to multiple repositories assumes the
+   existence of an attribute for traversal of the repositories.  The
+   definition of this attribute is considered a distributed registry
+   issue and is out of scope of this document.
+
+   The root repository must be initially populated at some epoch with a
+   few entries.  An initial maintainer is needed to add more
+   maintainers.  The referral-by attribute can be set to refer to itself
+   in this special case (Section 10 describes the referral-by).  When
+
+
+
+Villamizar, et al.          Standards Track                    [Page 17]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   adding an inetnum or a route object an existing exact match or a less
+   specific overlap must exist.  A route object may be added based on an
+   exact match or a less specific inetnum.  The root repository must be
+   initially populated with the allocation of an inetnum covering the
+   prefix 0/0, indicating that some address allocation authority exists.
+   Similarly an initial as-block is needed covering the full AS number
+   range.
+
+   When adding an object with no natural hierarchy, the search for an
+   existing object follows the procedure outlined in Section 9.8.
+
+   When adding an aut-num (an AS), the same procedure used in a query is
+   used to determine the appropriate repository for the addition and to
+   determine which maintainer applies.  The sequence of AS-block objects
+   and repository delegations is followed.  If the aut-num does not
+   exist, then the submission must match the authentication specified in
+   the maintainer for the most specific AS-block in order to be added.
+
+   The procedure for adding an inetnum is similar.  The sequence of
+   inet-num blocks is followed until the most specific is found.  The
+   submission must match the authentication specified in the maintainer
+   for the most specific inetnum overlapping the addition.
+
+   Adding a route object is somewhat more complicated.  The route object
+   submission must satisfy two authentication criteria.  It must match
+   the authentication specified in the aut-num and the authentication
+   specified in either a route object or if no applicable route object
+   is found, then an inetnum.
+
+   An addition is submitted with an AS number and prefix as its key.  If
+   the object already exists, then the submission is treated as a modify
+   (see Section 9.10).  If the aut-num does not exist on a route add,
+   then the addition is rejected (see Section C for further discussion
+   of tradeoffs).  If the aut-num exists then the submission is checked
+   against the applicable maintainer.  A search is then done for the
+   prefix first looking for an exact match.  If the search for an exact
+   match fails, a search is made for the longest prefix match that is
+   less specific than the prefix specified.  If this search succeeds it
+   will return one or more route objects.  The submission must match an
+   applicable maintainer in at least one of these route objects for the
+   addition to succeed.  If the search for a route object fails, then a
+   search is performed for an inetnum that exactly matches the prefix or
+   for the most specific inetnum that is less specific than the route
+   object submission.  The search for an inetnum should never fail but
+   it may return an unallocated or reserved range.  The inetnum status
+   must be "allocated" and the submission must match the maintainer.
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 18]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   Having found the AS and either a route object or inetnum, the
+   authorization is taken from these two objects.  The applicable
+   maintainer object is any referenced by the mnt-routes attributes.  If
+   one or more mnt-routes attributes are present in an object, the mnt-
+   by attributes are not considered.  In the absence of a mnt-routes
+   attribute in a given object, the mnt-by attributes are used for that
+   object.  The authentication must match one of the authorizations in
+   each of the two objects.
+
+   If the addition of a route object or inetnum contains a reclaim
+   attribute, then any more specific objects of the same type must be
+   examined.  The reclaim attribute can only be added if there are no
+   more specific overlaps or if the authentication on the addition is
+   present in the authorization of a less specific object that already
+   has a reclaim attribute covering the prefix range, or if the
+   authentication on the addition is authorized for the modification of
+   all existing more specific prefixes covered by the addition.
+
+9.10  Modifying or Deleting Database Objects
+
+   When modifying or deleting any existing object a search for the
+   object is performed as described in Section 9.8.  If the submission
+   matches an applicable maintainer for the object, then the operation
+   can proceed.  An applicable maintainer for a modification is any
+   maintainer referenced by the mnt-by attribute in the object.  For
+   route and inet-num objects an applicable maintainer may be listed in
+   a less specific object with a reclaim attribute.
+
+   If the submission is for a route object, a search is done for all
+   less specific route objects and inetnums.  If the submission is for
+   an inetnum, a search is done for all less specific inetnums.  If the
+   submission fails the authorization in the object itself but matches
+   the reclaim attribute in any of the less specific objects, then the
+   operation can proceed.  Section C contains discussion of the
+   rationale behind the use of the reclaim attribute.
+
+   A modification to an inetnum object that adds a reclaim attribute or
+   removes a no-reclaim attribute must be checked against all existing
+   inetnums that are more specific.  The same check of the reclaim
+   attribute that is made during addition must be made when a reclaim
+   attribute is added by a modification (see Section 9.9).
+
+   A deletion is considered a special case of the modify operation.  The
+   deleted object may remain in the database with a "deleted" attribute
+   in which case the mnt-by can still be consulted to remove the
+   "deleted" attribute.
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 19]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+10  Data Format Summaries
+
+   RIPE-181 [2] and RPSL [1] data is represented externally as ASCII
+   text.  Objects consist of a set of attributes.  Attributes are name
+   value pairs.  A single attribute is represented as a single line with
+   the name followed by a colon followed by whitespace characters
+   (space, tab, or line continuation) and followed by the value.  Within
+   a value all whitespace is equivalent to a single space.  Line
+   continuation is supported by a backslash at the end of a line or the
+   following line beginning with whitespace.  When transferred,
+   externally attributes are generally broken into shorter lines using
+   line continuation though this is not a requirement.  An object is
+   externally represented as a series of attributes.  Objects are
+   separated by blank lines.
+
+   There are about 80 attribute types in the current RIPE schema and
+   about 15 object types.  Some of the attributes are mandatory in
+   certain objects.  Some attributes may appear multiple times.  One or
+   more attributes may form a key.  Some attributes or sets of
+   attributes may be required to be unique across all repositories.
+   Some of the attributes may reference a key field in an object type
+   and may be required to be a valid reference.  Some attributes may be
+   used in inverse lookups.
+
+   A review of the entire RIPE or RPSL schema would be too lengthy to
+   include here.  Only the differences in the schema are described.
+
+10.1  Changes to the RIPE/RPSL Schema
+
+   One new object type and several attributes are added to the RIPE/RPSL
+   schema.  There are significant changes to the rules which determine
+   if the addition of an object is authorized.
+
+   The new object type is listed below.  The first attribute listed is
+   the key attribute and also serves as the name of the object type.
+
+   as-block        key  mandatory  single    unique
+   descr                optional   multiple
+   remarks              optional   multiple
+   admin-c              mandatory  multiple
+   tech-c               mandatory  multiple
+   notify               optional   multiple
+   mnt-by               mandatory  multiple
+   changed              mandatory  multiple
+   source               mandatory  single
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 20]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   In the above object type only the key attribute "as-block" is new:
+
+   as-block  This attribute provides the AS number range for an "as-
+      block" object.  The format is two AS numbers including the sub-
+      string "AS" separated by a "-" delimiter and optional whitespace
+      before and after the delimiter.
+
+   In order to support stronger authentication, the following keywords
+   are added to the "auth" attribute:
+
+   pgp-from  The remainder of the attribute gives the string identifying
+      a PGP identity whose public key is held in an external keyring.
+      The use of this method is deprecated in favor of the "pgpkey"
+      method.
+
+   pgpkey  See [18].
+
+   In order to disable authentication and give permission to anyone, the
+   authentication method "none" is added.  It has no arguments.
+
+   An additional change is the "auth" attribute is allowed to exist in a
+   "person" or "role" object.  The "auth" method "role" or "person" can
+   be used to refer to a role or person object and take the "auth"
+   fields from those objects.  Care must be taken in implementations to
+   detect circular references and terminate expansion or the references
+   already visited.
+
+   A few attributes are added to the schema.  These are:
+
+   mnt-routes  The mnt-routes attribute may appear in an aut-num, inet-
+      num, or route object.  This attribute references a maintainer
+      object which is used in determining authorization for the addition
+      of route objects.  After the reference to the maintainer, an
+      optional list of prefix ranges (as defined in RPSL) inside of
+      curly braces or the keyword "ANY" may follow.  The default, when
+      no additional set items are specified is "ANY" or all more
+      specifics.  The mnt-routes attribute is optional and multiple.
+      See usage details in Section 9.1.
+
+   mnt-lower  The mnt-lower attribute may appear in an inetnum, route,
+      as-block or aut-num object.  This attribute references a
+      maintainer object.  When used in an inetnum or route object the
+      effect is the same as a "mnt-routes" but applies only to prefixes
+      more specific than the prefix of the object in which it is
+      contained.  In an as block object, mnt-lower allows addition of
+      more specific as-block objects or aut-num objects.  In an aut-num
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 21]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+      object the mnt-lower attribute specifies a maintainer that can be
+      used to add objects with hierarchical names as described in
+      Section 9.7.
+
+   reclaim  The reclaim attribute may appear in as-block, aut-num,
+      inet-num, or route objects.  Any object of the same type below in
+      the hierarchy may be modified or deleted by the maintainer of the
+      object containing a reclaim attribute.  The value of the attribute
+      is a set or range of objects of the same type where the syntax of
+      the set or range is as defined in RPSL. See Section 9.5 for
+      restrictions on adding reclaim attributes.
+
+   no-reclaim  The no-reclaim attribute is used with the reclaim
+      attribute.  The no-reclaim attribute negates any reclaim attribute
+      it overlaps.  See Section 9.5 for restrictions on deleting no-
+      reclaim attributes.
+
+   referral-by  This attribute is required in the maintainer object.  It
+      may never be altered after the addition of the maintainer.  This
+      attribute refers to the maintainer that created this maintainer.
+      It may be multiple if more than one signature appeared on the
+      transaction creating the object.
+
+   auth-override  An auth-override attribute can be added, deleted, or
+      changed by a transaction submitted by maintainer listed in the
+      referral-by.  An auth-override can only be added to a maintainer
+      if that maintainer has been inactive for the prior 60 days.  The
+      auth-override attribute itself contains only the date when the
+      attribute will go into effect which must be at least 60 days from
+      the current date unless there is already authorization to modify
+      the maintainer.  After the date in the auth-override is reached,
+      those identified by the maintainer in the referral-by have
+      authorization to modify the maintainer.  This attribute exists as
+      a means to clean up should the holder of a maintainer become
+      unresponsive and can only take effect if that maintainer does not
+      remove the auth-override in response to the automatic notification
+      that occurs on changes.
+
+   The existing "mnt-by" attribute references the "maintainer" object
+   type.  The "mnt-by" attribute is now mandatory in all object types.
+   A new maintainer may be added by any existing maintainer.  The
+   "referral-by" attribute is now mandatory in the "maintainer" object
+   to keep a record of which maintainer made the addition and can never
+   be changed.  Maintainers cannot be deleted as long as they are
+   referenced by a "referral-by" attribute elsewhere.
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 22]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+A  Core and Non-Core Functionality
+
+   Most of the objects and attributes described in this document are
+   essential to the authorization framework.  These are referred to as
+   being part of the "core" functionality.  A few attributes listed here
+   are considered "non-core".
+
+   The "reclaim" and "no-reclaim" attributes are a convenience to
+   support flexibility in the implementation of address lending.
+
+   The "auth-override" attribute is a convenience to facilitate recovery
+   in an environment where repository data is redistributed in any way.
+
+   The "referal-by" attribute is a "core" feature.  An individual
+   registry may express its sutonomy by creating a self-referencing
+   maintainer, one whose "referal-by" points to itslef.  Other
+   registries can decide on a case by case basis whether to consider
+   such an entry valid.  A registry may only allow the "referal-by" to
+   refer to a specific maintainer under the control of the registry.
+   This further restriction is an issue that is purely local to the
+   registry.
+
+B  Examples
+
+   The examples below leave out some required attributes that are not
+   needed to illustrate the use of the objects and attributes described
+   in this document.  Missing are admin-c, tech-c, changed, source.
+   Also missing are attributes such as mnt-nfy, whose use are a good
+   practice but are not strictly required.
+
+   To do anything at all a maintainer is needed.  At some epoch a a
+   single maintainer is populated in one repository and that maintianer
+   has a referal-by pointing to itself.  All others referal-by
+   references can be traced back to that maintainer.  At the epoch the
+   as-block AS0- AS65535 and the inetnum 0.0.0.0-255.255.255.255 are
+   also allocated.  Other ancilliary object may also be needed to
+   bootstrap.
+
+      mntner:        ROOT-MAINTAINER
+      auth:          pgpkey-12345678
+
+      mnt-by:        ROOT-MAINTAINER
+      referal-by:    ROOT-MAINTAINER
+
+   This root maintainer might add a top level maintainer for some
+   organization.
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 23]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+      mntner:        WIZARDS
+      descr:         High level Technical Folks
+      auth:          pgpkey-23456789
+      auth:          pgpkey-3456789a
+      mnt-by:        WIZARDS
+      referal-by:    ROOT-MAINTAINER
+
+   That maintainer might add another who have more limited capabilities.
+
+      mntner:        MORTALS
+      descr:         Maintain day to day operations
+      auth:          pgpkey-456789ab
+      auth:          pgpkey-56789abc
+      auth:          pgpkey-6789abcd
+      mnt-by:        WIZARDS
+      referal-by:    WIZARDS
+
+   Note that the WIZARDS can change their own maintainer object and the
+   MORTALS maintainer object but MORTALS cannot.
+
+   At some point an as-block is allocated and broken down.  In the
+   example below, private number space is used.
+
+      as-block:      AS65500-AS65510
+      mnt-by:        SOME-REGISTRY
+      mnt-lower:     WIZARDS
+
+      Note that a registry has control over the object that they have
+      created representing the allocation, but have given the party to
+      which the allocation was made the ability to create more specific
+      objects. Below this as-block, an aut-num is added.  Note that
+      import and export are normally required for a aut-num but are not
+      shown here.
+
+      aut-num:       AS65501
+      mnt-by:        WIZARDS
+      mnt-lower:     MORTALS
+
+   In aut-num above the WIZARDS maintainer can modify the aut-num
+   itself.  The MORTALS maintainer can add route objects using this AS
+   as the origin if they also have authorization for the IP number space
+   in a less specific route or inetnum.
+
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 24]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   We also need an inetnum allocation.  In this example the inetnum is
+   allocated to a completely different organization.  Again attributes
+   are omited which would normally be needed in an inetnum.
+
+      inetnum:       192.168.144.0-192.168.151.255
+      mnt-by:        SOME-REGISTRY
+      mnt-lower:     ISP
+      reclaim:       ALL
+
+   The maintainer ISP can add more specific inetnums or routes with this
+   address space.  Note that the registry has declared their ability to
+   reclaim the address space.
+
+   If ISP wished to reclaim all allocations but some suballocation of
+   theirs resisted, we might get something like the following in which
+   they will reclaim only the top half of an allocation (possibly if it
+   remains unused).
+
+      inetnum:       192.168.144.0-192.168.147.255
+      mnt-by:        ISP
+      mnt-lower:     EBG-COM
+      reclaim:       192.168.146/23+
+
+   If we assume that the maintainer EBG-COM and the maintainer MORTALS
+   want to add a route object, one way to do it is for both parties to
+   sign.  If EBG-COM for some reason couldn't aggregate an allocate a
+   single top level route (which is inexcusable these days) or there was
+   a preference for some reason to avoid the joint signature approach on
+   a submission either party could give the other permission to make the
+   addition.  A mnt-routes could be added to the aut-num or a mnt-lower
+   could be added to an inetnum.
+
+      aut-num:       AS65501
+      mnt-by:        WIZARDS
+      mnt-lower:     MORTALS
+      mnt-routes:    EBG-COM {192.168.144/23}
+
+   With this change to the aut-num the maintainer EBG-COM could add a
+   route with origin AS65501, but only with a limited address range.
+
+      route:         192.168.144/24
+      origin:        AS65501
+      descr:         These boneheads don't aggregate
+      mnt-by:        EBG-COM
+      mnt-by:        FICTION::MORTALS
+
+   Note that while the maintainer EBG-COM added the object they allowed
+   the maintainer MORTALS the ability to modify it.
+
+
+
+Villamizar, et al.          Standards Track                    [Page 25]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   If an object ended up in another repository, a single maintainer
+   could still be used.  In the example above the notation
+   FICTION::MORTALS indicates that the route object is in a different
+   repository and rather than duplicate the maintainer, a reference is
+   made to the repository in which the MORTALS object resides.
+
+   In the example below, a pair of route-sets are added and hierarchical
+   names are used.
+
+      route-set:     AS65501:Customers
+      mnt-by:        WIZARDS
+      mnt-lower:     MORTALS
+
+      route-set:     AS65501:Customers:EBG-COM
+      mnt-by:        MORTALS
+      mnt-lower:     EBG-COM
+
+   Suppose in the 192.168.144/24 object above, only the EBG-COM
+   maintainer is listed.  If EBG-COM goes bankrupt, no longer needs
+   address space, and stops responding, it could be difficult to delete
+   this object.  The maintainer listed in the EBG-COM referral-by
+   attribute could be contacted.  They could add a auth-override
+   attribute to the EBG-COM object.  Later they could modify the EBG-COM
+   object and then any objects with EBG-COM in the mnt-by.
+
+      mntner:        EBG-COM
+      mnt-by:        EBG-COM
+      auth-override: 19990401
+
+   The examples above stray significantly from realism.  They do provide
+   simple illustrations of the usage of the objects type and attributes
+   described in this document and hopefully in doing some are of some
+   value.
+
+C  Technical Discussion
+
+   A few design tradeoffs exist.  Some of these tradeoffs, the selected
+   solution, and the alternatives are discussed here.  Some of the
+   issues are listed below.
+
+   1. Whether to err on the side of permissiveness and weaken
+      authorization controls or risk the possibility of erecting
+      barriers to registering information.
+
+   2. Whether to support enforcible address lending or provide the
+      smaller or end user with ultimate control over the registration of
+      the prefixes they are using.
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 26]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   3. What to do with older objects that either don't conform to newer
+      requirements regarding minimum authorization, authentication, and
+      accountability, or are of questionable validity.
+
+C.1  Relaxing requirements for ease of registry
+
+   If the requirement that an aut-num exists is relaxed, then it is
+   possible for anyone to make use of an unassigned AS number or make
+   use of an assigned AS number for which the aut-num has not been
+   entered.  Placing requirements on the entry of aut-num presumes
+   cooperation of the Internet address allocation authority (if separate
+   from the routing registry).  The address allocation authority must be
+   willing to field requests to populate skeleton aut-nums from the
+   party for which the allocation has been made.  These aut-num must
+   include a reference to a maintainer.  A request to the address
+   allocation authority must therefore include a reference to an
+   existing maintainer.
+
+   The ability to add route objects is also tied to the existence of
+   less specific route objects or inetnums.  The Internet address
+   allocation authority (if separate from the routing registry) must
+   also be willing to field requests to add inetnum records for the
+   party already allocated the address space.
+
+   The Internet address allocation authority should also add inetnums
+   and aut-nums for new allocations.  In order to do so, a maintainer
+   must exist.  If a party is going to connect to the Internet, they can
+   get a maintainer by making a request to the Internet service provider
+   they will be connecting to.  Once they have a maintainer they can
+   make a request for address space or an AS number.  The maintainer can
+   contain a public key for a cryptographicly strong authorization
+   method or could contain a "crypt-key" or "mail-to" authorization
+   check if that is considered adequate by the registering party.
+   Furthermore an address allocation authority should verify that the
+   request for an AS number or for address space matches the
+   authorization criteria in the maintainer.
+
+   Currently only the registries themselves may add maintainers.  This
+   becomes a problem for the registry, particularly in verifying public
+   keys.  This requirement is relaxed by allowing existing maintainers
+   to add maintainers.  Unfortunately the accountability trail does not
+   exist for existing maintainers.  The requirement then should be
+   relaxed such that existing maintainers may remain but only existing
+   maintainers that have a "referral-by" attribute can add maintainers.
+   The "referral-by" cannot be modified.  This requirement can be
+   relaxed slightly so that a "referral-by" can be added to a maintainer
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 27]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   by an existing maintainer with a "referral-by".  This will allow the
+   accountability trail to be added to existing maintainers and these
+   maintainers can then add new maintainers.
+
+   Verifying that a party is who they claim to be on initial addition,
+   is one of the problems that currently falls upon the AS number and
+   address registry.  This problem is reduced by allowing existing
+   maintainers to add maintainers.  This may actually make it easier to
+   get maintainers and therefore easier to register.  The number
+   authority still must verify that the AS or address space is actually
+   needed by the party making a request.
+
+   Authorization checks made during the addition of route objects that
+   refer to AS objects and inetnums strongly rely on the cooperation of
+   the Internet address allocation authorities.  The number authorities
+   must register as-blocks, aut-nums, or inetnums as AS numbers or
+   address space is allocated.  If only a subset of the number
+   authorities cooperate, then either an inetnum or as-block can be
+   created covering the space that registry allocates and essentially
+   requiring null allocation (for example a "crypt-pw" authentication
+   where the password is given in the remarks in the object or its
+   maintainer) or those obtaining addresses from that number authority
+   will have trouble registering in the routing registry.  The
+   authorization model supports either option, though it would be
+   preferable if the number authorities cooperated and the issue never
+   surfaced in practice.
+
+   The maintainer requirements can be relaxed slightly for existing
+   maintainers making it easier to register.  Relaxing requirements on
+   other objects may defeat the authorization model, hence is not an
+   option.
+
+C.2  The address lending issue
+
+   The issue of whether lending contracts should be enforcible is an
+   issue of who should ultimately be able to exercise control over
+   allocations of address space.  The routing registry would be wise to
+   stay as neutral as possible with regard to disputes between third
+   parties.  The "reclaim" and "no-reclaim" are designed to allow either
+   outcome to the decision as to whether the holder of a less specific
+   inetnum or route object can exercise control over suballocations in
+   the registry.  The routing registry itself must decide whether to
+   retain control themselves and if so, should very clearly state under
+   what conditions the registry would intervene.  A registry could even
+   go to the extreme of stating that they will intervene in such a
+   dispute only after the dispute has been resolved in court and a court
+   order has been issued.
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 28]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   When an allocation is made by a registry, the registry should keep a
+   "reclaim" attribute in the less specific object and make a strong
+   policy statement that the reclaim privilege will not be used except
+   under very clearly defined special circumstances (which at the very
+   minimum would include a court order).  If the allocation is further
+   subdivided the party subdividing the allocation and the party
+   accepting the suballocation must decide whether a "reclaim" can be
+   kept by the holder of the less specific allocation or whether a "no-
+   reclaim" must be added transferring control to the holder of the more
+   specific.  The registry is not involved in that decision.  Different
+   pairs of third parties may reach different decisions regarding the
+   "reclaim" and any contractual restrictions on its use that may be
+   expressed outside of the registry in the form of a legal contract and
+   ultimately resolved by the courts in the event of a bitter dispute.
+
+   By retaining "reclaim" rights the registry retains the ability to
+   abide by a court order.  This may only truly become an issue in a
+   distributed registry environment where registries will be rechecking
+   the authorization of transactions made elsewhere and may fail to
+   process the attempt of another registry to abide by a court order by
+   overriding normal authorization to change the registry contents if a
+   reclaim is not present.
+
+C.3  Dealing with non-conformant or questionable older data
+
+   Some of the newer requirements include requiring that all objects
+   reference a maintainer object responsible for the integrity of the
+   object and requiring accountability for the creation of maintainers
+   to be recorded in the maintainer objects so that accountability can
+   be traced back from an unresponsive maintainer.  In the event that
+   contact information is absent or incorrect from objects and there is
+   any question regarding the validity of the objects, the maintainer
+   can be contacted.  If the maintainer is unresponsive, the maintainer
+   that authorized the addition of that maintainer can be contacted to
+   either update the contact information on the maintainer or confirm
+   that the entity no longer exists or is no longer actively using the
+   Internet or the registry.
+
+   Many route objects exist for which there are no maintainers and for
+   which inetnum and AS objects do not exist.  Some contain the now
+   obsoleted guardian attribute rather than a mnt-by.
+
+   It is not practical to unconditionally purge old data that does not
+   have maintainers or does not conform to the authorization hierarchy.
+   New additions must be required to conform to the new requirements
+   (otherwise the requirements are meaningless).  New requirements can
+   be phased in by requiring modifications to conform to the new
+   requirements.
+
+
+
+Villamizar, et al.          Standards Track                    [Page 29]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   A great deal of questionable data exists in the current registry.
+   The requirement that all objects have maintainers and the
+   requirements for improved accountability in the maintainers
+   themselves may make it easier to determine contact information even
+   where the objects are not updated to reflect contact information
+   changes.
+
+   It is not unreasonable to require valid contact information on
+   existing data.  A great deal of data appears to be unused, such as
+   route objects for which no announcement has been seen in many months
+   or years.  An attempt should be made to contact the listed contacts
+   in the object, in the maintainer if there is one, then up the
+   maintainer referral-by chain if there is one, and using the number
+   registry or origin AS contact information if there is no maintainer
+   accountability trail to follow.  Experience so far indicates that the
+   vast majority of deletions identified by comparing registered
+   prefixes against route dumps will be positively confirmed (allowing
+   the deletion) or there will be no response due to invalid contact
+   information (in many cases the IRR contact information points to
+   nsfnet-admin@merit.edu).
+
+   By allowing the registry to modify (or delete) any objects which are
+   disconnected from the maintainer accountability trail, cleanup can be
+   made possible (though mail header forging could in many cases have
+   the same effect it is preferable to record the fact that the registry
+   itself made the cleanup).  Similarly, a mechanism may be needed in
+   the future to allow the maintainer in the referral-by to override
+   maintainer privileges in a referred maintainer if all contacts have
+   become unresponsive for a maintainer.  The referral-by maintainer is
+   allowed to add an "auth-override" attribute which becomes usable as
+   an "auth" within 60 days from the time of addition.  The maintainer
+   themselves would be notified of the change and could remove the
+   "auth-override" attribute before it becomes effective and inquire as
+   to why it was added and correct whatever problem existed.  This can
+   be supported immediately or added later if needed.
+
+D  Common Operational Cases
+
+   In principle, address allocation and route allocation should be
+   hierarchical with the hierarchy corresponding to the physical
+   topology.  In practice, this is often not the case for numerous
+   reasons.  The primary reasons are the topology is not strictly tree
+   structured and the topology can change.  More specificly:
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 30]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   1. The Internet topology is not strictly tree structured.
+
+      o  At the top level the network more closely resembles a
+         moderately dense mesh.
+
+      o  Near the bottom level many attachments to the Internet are
+         multi-homed to more than one Internet provider.
+
+   2. The Internet topology can and does change.
+
+      o  Many attachments switch providers to obtain better service or
+         terms.
+
+      o  Service providers may modify adjacencies to obtain better
+         transit service or terms.
+
+      o  Service providers may disappear completely scattering
+         attachments or they may merge.
+
+   Renumbering is viewed as a practical means to maintain a strict
+   numeric hierarchy [16].  It is also acknowledged that renumbering
+   IPv4 networks can be difficult [16, 3, 17].  We examine first the
+   simple case where hierarchy still exists.  We then examine the
+   operational cases where either initial topology is not tree
+   structured or cases where topology changes.
+
+D.1  simple hierarchical address allocation and route allocation
+
+   This is the simplest case.  Large ranges of inetnums are assigned to
+   address registries.  These registries in turn assign smaller ranges
+   for direct use or to topologically large entities where allocations
+   according to topology can reduce the amount of routing information
+   needed (promote better route aggregation).
+
+   AS objects are allocated as topology dictates the need for additional
+   AS [10].  Route objects can be registered by those with authorization
+   given by the AS and by the address owner.  This is never an issue
+   where the maintainer of the AS and the inetnum are the same.  Where
+   they differ, either the provider can give permission to add route
+   objects for their AS, or the party allocated the address space can
+   give the provider permission to add route objects for their address
+   space, or both parties can sign the transaction.  Permission is
+   provided by adding to maintainer attributes.
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 31]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+D.2  aggregation and multihomed more specific routes
+
+   Aggregation is normally not a problem if a provider is aggregating
+   address space allocated to the provider and then suballocated
+   internally and/or to customers.  In fact, the provider would be
+   expected to do so.  This is not a problem even if the route object
+   for the aggregation is added after the more specific route objects
+   since only less specific objects are considered.
+
+   Aggregation is potentially a problem if a provider or a set of
+   providers plan to aggregate address space that was never explicitly
+   allocated as a block to those providers but rather remains the
+   allocation of a address registry.  These large aggregations can be
+   expected to be uncommon, but relatively easily dealt with.
+   Superaggregates of this type will generally be formed by
+   topologically close entities who have also managed to draw adjacent
+   address allocations.  In effect, the registry must give permission to
+   form such a superaggregate by either giving permission to do so in
+   the mnt-routes of an inetnum or by signing the submission along with
+   the other parties.
+
+D.3  provider independent addresses and multiple origin AS
+
+   Provider independent addresses and multihoming arrangement using
+   multiple origin AS present a similar problem to multihoming.  The
+   maintainer of the address space and the maintainer of the AS is not
+   the same.  Permission can be granted using mnt-routes or multiple
+   signatures can appear on the submission.
+
+D.4  change in Internet service provider
+
+   A change in Internet service providers is similar to multihoming.  A
+   minor difference is that the AS for the more specific route will be
+   the AS of the new provider rather than the AS of the multihomed
+   customer.  Permission can be granted using mnt-routes or multiple
+   signatures can appear on the submission.
+
+D.5  renumbering grace periods
+
+   Renumbering grace periods allow a provider who wants to keep an
+   address allocation intact to allow a customer who has chosen to go to
+   another provider to renumber their network gradually and then return
+   the address space after renumbering is completed.  The issue of
+   whether to require immediate renumbering or offer renumbering grace
+   periods and how long they should be or whether they should be
+   indefinite has been topic of bitter disputes.  The authorization
+   model can support no renumbering grace period, a finite renumbering
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 32]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   grace period, or an indefinite renumbering grace period.  The
+   "reclaim" attribute described in Section 9.1 provides a means to end
+   the grace period.
+
+E  Deployment Considerations
+
+   This section describes deployment considerations.  The intention is
+   to raise issues and discuss approaches rather than to provide a
+   deployment plan.
+
+   The use of routing registries is not yet universally accepted.  There
+   still remain Internet providers who see no reason to provide the
+   added assurance of accurate routing information described in Section
+   6.  More accurately, these benefits are viewed as being insufficient
+   to justify the cost.  This has been largely caused an inability of a
+   very major router vendor up until recently to handle prefix lists of
+   the size needed to specify routing policy on a per prefix basis.
+
+   Another reason cited is that filtering on a prefix basis in an
+   environment where routing registry information is incomplete or
+   inaccurate can interfere with connectivity.
+
+   There clearly is a critical mass issue with regard to the use of
+   routing registries.  A minority of providers use the existing IRR to
+   filter on a per prefix basis.  Another minority of providers do not
+   support the IRR and generally fail to register prefixes until
+   connectivity problems are reported.  The majority of providers
+   register prefixes but do not implement strict prefix filtering.
+
+   Deploying new authentication mechanisms has no adverse consequences.
+   This has been proven with Merit's deployment of PGP.
+
+   In deploying new authorization mechanisms, a major issue is dealing
+   with existing data of very questionable origin.  A very large number
+   of route objects refer to prefixes that have not been announced for
+   many years.  Other route objects refer to prefixes that are no longer
+   announced with the origin AS that they are registered with (some were
+   incorrectly registered to start with).  There are many causes for
+   this.
+
+   1. During the transition from the NSFNET PRDB to the RADB a large
+      number of prefixes were registered with an origin AS corresponding
+      to the border AS at which the NSFNET had once heard the route
+      announcements.  The PRDB did not support origin AS, so border AS
+      was used.  Many of these routes were no longer in use at the time
+      and are now routed with a submitter listed as "nsfnet-
+      admin@merit.edu".
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 33]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   2. As CIDR was deployed, aggregates replaced previously separately
+      announced more specific prefixes.  The route objects for the more
+      specific prefixes were never withdrawn from the routing
+      registries.
+
+   3. Some prefixes are simply no longer in use.  Some networks have
+      been renumbered.  Some network no longer exist.  Often the routing
+      registry information is not withdrawn.
+
+   4. As provider AS adjacencies changed and as end customers switched
+      providers often the actual origin AS changed.  This was often not
+      reflected by a change in the routing registry.
+
+   Inaccuracies will continue to occur due to the reasons above, except
+   the first.  The hierarchical authorization provides greater
+   accountability.  In the event that the contacts for specific objects
+   become unresponsive traversal up the authorization hierarchy should
+   help identify the parties having previous provided authorization.
+   These contacts may still have sufficient authorization to perform the
+   necessary cleanup.  This issue is discussed in Section C.
+
+   A great deal of information is currently missing in the IRR. Quite a
+   few AS have no aut-num.  Quite a lot of data has no maintainer and
+   the vast majority of maintainers use only the weakest of
+   authentication methods.  Very little can be done by the registries to
+   correct this.  The defaults in the cases of missing objects needed
+   for authorization has to be to make no authentication checks at all.
+
+   The transition can be staged as follows:
+
+   1. Add and make use of stronger authorization models.
+
+   2. Make schema modifications necessary to support delegations.
+
+   3. Add delegation attributes needed for query traversal.
+   4. Base query traversal on delegations rather than a search of all
+      known registries.
+
+   5. Obtain the cooperation of the address registries for the purpose
+      of populating the "inetnum" entries on an ongoing basis.
+
+   6. Add hierarchical authorization support for critical object types,
+      "aut-num", "inetnum" and "route".
+
+   7. Add the requirement that database object either be in use or have
+      valid contact information and if queries are made by the registry
+      a response from a contact indicating that the object serves a
+      purpose if it is not clear what its use is.
+
+
+
+Villamizar, et al.          Standards Track                    [Page 34]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   8. Begin to purge data which is clearly not in use and for which
+      there is no valid contact information or no response from the
+      contacts.
+
+   Deployment of hierarchical authorization requires cooperation among
+   the existing routing registries.  New code will have to be deployed.
+   In some cases minimal development resources are available and
+   substantial inertia exists due to the reliance on the current
+   repository and the need to avoid disruption.
+
+   If hierarchical authorization of route objects depends on the
+   existence of address registration information, minimal cooperation of
+   the currently separate address registries is required.  The extent of
+   the cooperation amounts to sending cryptographically signed
+   transactions from the address registry to the number registry as
+   address allocations are made or providing equivalent access to new
+   address allocations.
+
+   Currently most registries return query results from all of the known
+   repositories using their mirrored copies.  Cross registry
+   authorizations are not yet implemented.  Minimal schema changes have
+   to be made to support the ability to delegate objects for which there
+   is an authorization hierarchy and to support queries and references
+   to other repositories.  In the case of AS delegations, "as-block"
+   need to be created solely for the purpose of traversal.
+
+F  Route Object Authorization Pseudocode
+
+   The following list provides a brief review of basic concepts.
+
+   1. The route object submission must satisfy two authentication
+      criteria.  It must match the authentication specified in the aut-
+      num and the authentication specified in either a route object or
+      if no applicable route object is found, then an inetnum.
+
+   2. When checking for prefix authorization, an exact route object
+      prefix match is checked for first.  If there is not an exact match
+      then a longest prefix match that is less specific than the prefix
+      is searched for.  If the route prefix search fails, then a search
+      is performed for an inetnum that exactly matches the prefix or for
+      the most specific inetnum that is less specific than the route
+      object submission.
+
+      The search for an inetnum should never fail but it may return an
+      unallocated or reserved range.  The inetnum status must be
+      "allocated" and the submission must pass it's maintainer
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 35]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+      authorization in order to get authorization from an inetnum.  So
+      an unallocated or reserved range inetnum will cause the route
+      object submission to fail.
+
+   3. A route object must pass authorization from both the referenced
+      aut-num object and the route or inetnum object.  Authorization
+      shall be tested using the maintainer(s) referenced in the "mnt-
+      routes" attribute(s) first.  If that check fails, the "mnt-lower"
+      attributes are checked.  If that check fails the "mnt-by"
+      attributes are used for the authorization check.
+
+   4. The "reclaim" attribute can appear in inetnum, route and as-block
+      objects and provides a means to support address lending. "reclaim"
+      gives authorization over more specific objects, regardless of the
+      "mnt-by" in the object.  The value of a "reclaim" attribute can be
+      a list or set of objects to provide finer grain control.
+
+      The "reclaim" attribute is important to this discussion since it
+      affects prefix/origin authentication when a new route object is
+      submitted.
+
+      The "no-reclaim" attribute is used to provide explicit exceptions.
+
+   The following pseudocode outlines the algorithm used to check for
+   proper authorization of a route object submission.
+
+    Case #1.  Route object add
+              (ie, no exact prefix/origin match exists).
+
+    /* first check the aut-num authorization */
+
+    if ( the referenced aut-num object does not exist or
+         the aut-num authorization fails )
+      authorization fails
+
+    /* next we check for prefix authorization */
+
+    if ( a less specific route(s) with the longest prefix is found ) [
+      if ( authorization does not pass for at least one of the less
+           specific route(s) )
+        authorization fails
+
+    /* now check for a "reclaim" attr */
+
+      if ( the object has a "reclaim" attribute ) [
+        if ( no more-specifics exist
+             OR a less specific exists which passes
+                authorization and has a "reclaim" attribute
+
+
+
+Villamizar, et al.          Standards Track                    [Page 36]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+             OR all more specifics routess pass modify authorization )
+          authorization passes
+        else
+          authorization fails
+      ] else
+        authorization passes
+    ]
+
+    /* there are no less specific routes to check for prefix
+       authentication, so we need to try and get authorization from an
+       inetnum object */
+
+    if ( ( an inetnum is found that is an exact match
+           OR is less specific and it's status is "allocated" )
+         AND a maintainer referenced by the inetnum
+             passes authorization )
+      authorization succeeds
+
+    /* if there is no inetnum or route object then then
+       authorization fails.  This should never happen if
+       the DB is initialized properly. */
+
+    authorization fails.
+
+    Case #2.  Route object modify/delete
+              (ie, exact prefix/origin match exists).
+
+    if ( the mnt-by passes authorization )
+      authorization succeeds
+
+    /* if the authorization did not pass from the matched object,
+       we can still get authorization from a less specific route if it
+       has a "reclaim" attribute and we pass authorization */
+
+    if ( a less specific route or inetnum object passes authorization
+         AND has a "reclaim" attribute applicable to
+             the object to be modified )
+      authorization succeeds
+    else
+      authorization fails
+
+Acknowledgments
+
+   This document draws ideas from numerous discussions and contributions
+   of the IETF Routing Policy System Work Group and RIPE Routing Work
+   Group.  Earlier drafts of this document listed Carol Orange as a co-
+   author.  Carol Orange made contributions to this document while at
+   RIPE.
+
+
+
+Villamizar, et al.          Standards Track                    [Page 37]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+   Gerald Winters provided the pseudocode in an email message to the
+   RIPE dbsec mailing list that was the basis of the pseudocode found in
+   appendix F.  Susan Harris provided comments and numerous editorial
+   corrections.
+
+Intellectual Property Notice
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+References
+
+    [1]  Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer,
+         D., Terpstra M. and C. Villamizar, "Routing Policy
+         Specification Language (RPSL)", RFC 2280, January 1998.
+
+    [2]  Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M.,
+         Karrenberg, D., Terpstra, M. and J. Yu, "Representation of IP
+         Routing Policies in a Routing Registry (ripe-81++)", RFC 1786,
+         March 1995.
+
+    [3]  Berkowitz, H., "Router Renumbering Guide", RFC 2072, January
+         1997.
+
+    [4]  Braun, H-W., "Models of policy based routing", RFC 1104, June
+         1989.
+
+    [5]  Braun, H-W. and Y. Rekhter, "Advancing the NSFNET routing
+         architecture", RFC 1222, May 1991.
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 38]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+    [6]  Clark, D., "Policy routing in Internet protocols", RFC 1102,
+         May 1989.
+
+    [7]  Crocker, D., "Standard for the format of ARPA Internet text
+         messages", STD 11, RFC 822, August 1982.
+
+    [8]  Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-
+         Domain Routing (CIDR): an Address Assignment and Aggregation
+         Strategy", RFC 1519, September 1993.
+
+    [9]  Internet Engineering Steering Group and R. Hinden,
+         "Applicability Statement for the Implementation of Classless
+         Inter-Domain Routing (CIDR)", RFC 1517, September 1993.
+
+   [10]  Hawkinson, J. and T. Bates, "Guidelines for creation,
+         selection, and registration of an Autonomous System (AS)", RFC
+         1930, March 1996.
+
+   [11]  Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J.
+         Postel, "Internet Registry IP Allocation Guidelines", BCP 12,
+         RFC 2050, November 1996.
+
+   [12]  Knopper, M.  and S. Richardson, "Aggregation Support in the
+         NSFNET Policy-Based Routing Database", RFC 1482, June 1993.
+
+   [13]  Meyer, D., Prior, M., Alaettinoglu, C., Schmitz, J. and Carol
+         Orange, "Using RPSL in Practice", RFC 2650, August 1999.
+
+   [14]  Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787,
+         April 1995.
+
+   [15]  Rekhter Y. and T. Li, "An Architecture for IP Address
+         Allocation with CIDR", RFC 1518, September 1993.
+
+   [16]  Rekhter Y. and T. Li, "Implications of Various Address
+         Allocation Policies for Internet Routing", RFC 2008, October
+         1996.
+
+   [17]  Rekhter, Y., Lothberg, P., Hinden, R., Deering, S. and J.
+         Postel, "An IPv6 Provider-Based Unicast Address Format", RFC
+         2073, January 1997.
+
+   [18]  Zsako, J., "PGP Authentication for RIPE Database Updates", RFC
+         2726, December 1999.
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 39]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+Security Considerations
+
+   This document primarily addresses authorization rules for making
+   additions, deletions, and changes to routing policy information
+   repositories.  The authentication of these transactions through
+   strong cryptographic means are addressed by [18], referenced
+   thorughout this document.  The authorization rules are designed such
+   that the integrity of any transaction can be verified independently
+   by any party mirroring a repository to insure that rules are adhered
+   to.  To accomplish this the mirror must contain data already known to
+   be properly authorized.  In other words, the mirror must be complete
+   and authentication and authorization checks must be made continuously
+   as changes to the repository are recieved and processed in order.
+
+   Authentication alone does not provide a complete security model.
+   Current practice specifies authorization for deletions and changes
+   only, not for additions.  The authorization rules provide here
+   complete the security model for additions, deletions, and changes by
+   very explicitly defining rules for addition and clarifying procedures
+   for handling exception cases such as organizations which have ceased
+   to exist and therefore become entirely unresponsive.
+
+   Authentication and authorization of queries is explicitly stated to
+   be out of scope of this document.
+
+Authors' Addresses
+
+   Curtis Villamizar
+   Avici Systems
+   EMail: curtis@avici.com
+
+
+   Cengiz Alaettinoglu
+   ISI
+   EMail: cengiz@ISI.EDU
+
+
+   David M. Meyer
+   Cisco
+   EMail: dmm@cisco.com
+
+
+   Sandy Murphy
+   Trusted Information Systems
+   EMail: sandy@tis.com
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 40]
+
+RFC 2725             Routing Policy System Security        December 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 41]
+