path: root/doc/rfc/rfc2725.txt

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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L