GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2725

Network Working Group C. Villamizar Request for Comments: 2725 Avici Category: Standards Track C. Alaettinoglu

                                                                   ISI
                                                              D. Meyer
                                                                 Cisco
                                                             S. Murphy
                                                                   TIS
                                                         December 1999
                   Routing Policy System Security

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

 The RIPE database specifications and RPSL language define languages
 used as the basis for representing information in a routing policy
 system.  A repository for routing policy system information is known
 as a routing registry.  A routing registry provides a means of
 exchanging information needed to address many issues of importance to
 the operation of the Internet.  The implementation and deployment of
 a routing policy system must maintain some degree of integrity to be
 of any operational use.  This document addresses the need to assure
 integrity of the data by providing an authentication and
 authorization model.

Villamizar, et al. Standards Track [Page 1] RFC 2725 Routing Policy System Security December 1999

Table of Contents

 1  Overview  . . . . . . . . . . . . . . . . . . . . . . . . .  3
 2  Background  . . . . . . . . . . . . . . . . . . . . . . . .  3
 3  Implicit Policy Assumptions . . . . . . . . . . . . . . . .  5
 4  Scope of Security Coverage  . . . . . . . . . . . . . . . .  5
 5  Organization of this Document   . . . . . . . . . . . . . .  6
 6  Goals and Requirements  . . . . . . . . . . . . . . . . . .  6
 7  Data Representation . . . . . . . . . . . . . . . . . . . . 10
 8  Authentication Model  . . . . . . . . . . . . . . . . . . . 10
 9  Authorization Model . . . . . . . . . . . . . . . . . . . . 12
   9.1   Maintainer Objects . . . . . . . . . . . . . . . . . . 12
   9.2   as-block and aut-num objects . . . . . . . . . . . . . 13
   9.3   inetnum objects  . . . . . . . . . . . . . . . . . . . 13
   9.4   route objects  . . . . . . . . . . . . . . . . . . . . 14
   9.5   reclaim and no-reclaim attributes  . . . . . . . . . . 14
   9.6   Other Objects  . . . . . . . . . . . . . . . . . . . . 15
   9.7   Objects with AS Hierarchical Names . . . . . . . . . . 16
   9.8   Query Processing . . . . . . . . . . . . . . . . . . . 16
   9.9   Adding to the Database . . . . . . . . . . . . . . . . 17
   9.10  Modifying or Deleting Database Objects . . . . . . . . 19
 10  Data Format Summaries  . . . . . . . . . . . . . . . . . . 20
   10.1  Changes to the RIPE/RPSL Schema  . . . . . . . . . . . 20
 Appendicies
 A  Core and Non-Core Functionality . . . . . . . . . . . . . . 23
 B  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . 23
 C  Technical Discussion  . . . . . . . . . . . . . . . . . . . 26
   C.1   Relaxing requirements for ease of registry   . . . . . 27
   C.2   The address lending issue  . . . . . . . . . . . . . . 28
   C.3   Dealing with non-conformant or questionable older
         data . . . . . . . . . . . . . . . . . . . . . . . . . 29
 D  Common Operational Cases  . . . . . . . . . . . . . . . . . 30
   D.1   simple hierarchical address allocation and route
         allocation . . . . . . . . . . . . . . . . . . . . . . 31
   D.2   aggregation and multihomed more specific routes  . . . 32
   D.3   provider independent addresses and multiple origin
         AS . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   D.4   change in Internet service provider  . . . . . . . . . 32
   D.5   renumbering grace periods  . . . . . . . . . . . . . . 32
 E  Deployment Considerations . . . . . . . . . . . . . . . . . 33
 F  Route Object Authorization Pseudocode . . . . . . . . . . . 35
 Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 37
 Intellectual Property Notice . . . . . . . . . . . . . . . . . 38
 References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
 Security Considerations  . . . . . . . . . . . . . . . . . . . 40
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
 Full Copyright Statement   . . . . . . . . . . . . . . . . . . 41

Villamizar, et al. Standards Track [Page 2] RFC 2725 Routing Policy System Security December 1999

1 Overview

 The Internet Routing Registry (IRR) has evolved to meet a need for
 Internet-wide coordination.  This need was described in RFC-1787, an
 informational RFC prepared on behalf of the IAB [14].  The following
 summary appears in Section 7 of RFC-1787.
    While ensuring Internet-wide coordination may be more and more
    difficult, as the Internet continues to grow, stability and
    consistency of the Internet-wide routing could significantly
    benefit if the information about routing requirements of various
    organizations could be shared across organizational boundaries.
    Such information could be used in a wide variety of situations
    ranging from troubleshooting to detecting and eliminating
    conflicting routing requirements.  The scale of the Internet
    implies that the information should be distributed.  Work is
    currently underway to establish depositories of this information
    (Routing Registries), as well as to develop tools that analyze, as
    well as utilize this information.
 A routing registry must maintain some degree of integrity to be of
 any use.  The degree of integrity required depends on the usage of
 the routing policy system.
 An initial intended usage of routing policy systems such as the RIPE
 database had been in an advisory capacity, documenting the intended
 routing policies for the purpose of debugging.  In this role a very
 weak form of authentication was deemed sufficient.
 The IRR is increasingly used for purposes that have a stronger
 requirement for data integrity and security.  This document addresses
 issues of data integrity and security that is consistent with the
 usage of the IRR and which avoids compromising data integrity and
 security even if the IRR is distributed among less trusted
 repositories.

2 Background

 An early routing policy system used in the NSFNET, the policy routing
 database (PRDB), provided a means of determining who was authorized
 to announce specific prefixes to the NSFNET backbone.  The need for a
 policy database was recognized as far back as 1989 [6, 4].  By 1991
 the database was in place [5].  Authentication was accomplished by
 requiring confirmation and was a manually intensive process.  This
 solved the problem for the NSFNET, but was oriented toward holding
 the routing policy of a single organization.

Villamizar, et al. Standards Track [Page 3] RFC 2725 Routing Policy System Security December 1999

 The problem since has become more difficult.  New requirements have
 emerged.
 1. There is a need to represent the routing policies of many
    organizations.
 2. CIDR and overlapping prefixes and the increasing complexity of
    routing policies and the needs of aggregation have introduced new
    requirements.
 3. There is a need to assure integrity of the data and delegate
    authority for the data representing specifically allocated
    resources to multiple persons or organizations.
 4. There is a need to assure integrity of the data and distribute the
    storage of data subsets to multiple repositories.
 The RIPE effort specificly focused on the first issue and needs of
 the European community.  Its predecessor, the PRDB, addressed the
 needs of a single organization, the NSF. The RIPE database formats as
 described in [2] were the basis of the original IRR.
 Routing protocols themselves provide no assurance that the
 origination of a route is legitimate and can actually reach the
 stated destination.  The nature of CIDR allows more specific prefixes
 to override less specific prefixes [9, 15, 8].  Even with signed
 route origination, there is no way to determine if a more specific
 prefix is legitimate and should override a less specific route
 announcement without a means of determining who is authorized to
 announce specific prefixes.  Failing to do so places no assurance of
 integrity of global routing information and leaves an opportunity for
 a very effective form of denial of service attack.
 The Routing Policy System Language (RPSL) [1, 13] was a fairly
 substantial evolutionary step in the data representation which was
 largely targeted at addressing the second group of needs.  The PRDB
 accommodated CIDR in 1993 [12] and the RIPE database accommodated the
 entry of CIDR prefixes from inception, but RPSL provides many needed
 improvements including explicit support for aggregation.
 This document addresses the third group of needs identified above.
 While the current implementation supporting weak authentication
 doesn't guarantee integrity of the data, it does provide extensive
 mechanisms to make sure that all involved parties get notified when a
 change is made to the database, whether the change was malicious or
 intended.  This provides inadequate protection against additions.
 Since the software is increasingly used to configure the major parts

Villamizar, et al. Standards Track [Page 4] RFC 2725 Routing Policy System Security December 1999

 of the Internet infrastructure, it is not considered to be adequate
 anymore to know about and have the ability roll back unintended
 changes.  Therefore, more active security mechanisms need to be
 developed to prevent such problems before they happen.
 A separate document will be needed to address the fourth group of
 needs.

3 Implicit Policy Assumptions

 The authorization model encodes certain policies for allocation of
 address numbers, AS numbers, and for the announcement of routes.
 Implicit to the authorization model is a very limited number of
 policy assumptions.
 1. Address numbers are allocated hierarchically.  The IANA delegates
    portions of the address space to the regional registries
    (currently ARIN, APNIC and RIPE), which in turn delegate address
    space to their members, who can assign addresses to their
    customers.
 2. AS numbers are allocated either singly or in small blocks by
    registries.  Registries are allocated blocks of AS numbers,
    thereby making the allocation hierarchical.
 3. Routes should only be announced with the consent of the holder of
    the origin AS number of the announcement and with the consent of
    the holder of the address space.
 4. AS numbers and IP address registries may be different entities
    from routing registries.
 For subsets of any of these three allocation spaces, network
 addresses, AS numbers, and routes, these restrictions may be loosened
 or disabled by specifying a very weak authorization method or an
 authentication method of "none".  However, even when no
 authentication mechanism is used, all involved parties can be
 notified about the changes that occurred through use of the existing
 "notify" attribute.

4 Scope of Security Coverage

 This document is intended only to provide an authentication and
 authorization model to insure the integrity of the policy data in a
 registry.  Only authetication and authorization of additions,
 deletions, and changes to the database are within the scope of this
 document.  Authentication and authorization of database queries is

Villamizar, et al. Standards Track [Page 5] RFC 2725 Routing Policy System Security December 1999

 explicitly out of scope.  Mutual authentication of queries, that is
 authenticating both the origin of the query and the repository from
 which query results are obtained, is also out of scope.

5 Organization of this Document

 Familiarity with RIPE-181 [2] and RPSL [1] is assumed throughout this
 document.  Goals are described in Section 6.  Section 7 through
 Section 9 provide descriptions of the changes and discussion.
 Section 10 provides a concise summary of data formats and semantics.
 Appendix C through Appendix E provide additional technical
 discussion, examples, and deployment considerations.
    Goals and Requirements Section 6 provides a more detailed
    description of the issues and identifies specific problems that
    need to be solved, some of which require a degree of cooperation
    in the Internet community.
    Data Representation Section 7 provides some characteristics of
    RPSL and formats for external representations of information.
    Authentication Model Section 8 describes current practice,
    proposes additional authentication methods, and describes the
    extension mechanism if additional methods are needed in the
    future.
    Authorization Model Section 9 describes the means of determining
    whether a transaction contains the authorization needed to add,
    modify, or delete specific data objects, based on stated
    authentication requirements in related data objects.
    Data Format Summaries Section 10 provides a concise reference to
    the data formats and steps in transaction processing.
    Technical Discussion Section C contains some discussion of
    technical tradeoffs.
    Common Operational Cases Section D provides some examples drawn
    from past operational experience with the IRR.
    Deployment Considerations Section E describes some deployment
    issues and discusses possible means of resolution.

6 Goals and Requirements

 The Internet is an open network.  This openness and the large scale
 of the Internet can present operational problems.  Technical
 weaknesses that allow misconfiguration or errant operation in part of

Villamizar, et al. Standards Track [Page 6] RFC 2725 Routing Policy System Security December 1999

 the network to propagate globally or which provide potentials for
 simple denial of service attacks should be eliminated to the extent
 that it is practical.  The integrity of routing information is
 critical in assuring that traffic goes where it is supposed to.
 An accidental misconfiguration can direct traffic toward routers that
 cannot reach a destination for which they are advertising
 reachability.  This is commonly caused by misconfigured static routes
 though there are numerous other potential causes.  Static routes are
 often used to provide constant apparent reachability to single homed
 destinations.  Some of the largest ISPs literally have thousands of
 static routes in their networks.  These are often entered manually by
 operators.  Mistyping can divert traffic from a completely unrelated
 destination to a router with no actual reachability to the advertised
 destination.  This can happen and does happen somewhat regularly.  In
 addition, implementation bugs or severe misconfigurations that result
 in the loss of BGP AS path information or alteration of prefix length
 can result in the advertisement of large sets of routes.  Though
 considerably more rare, on a few occasions where this has occurred
 the results were catastrophic.
 Where there is the potential for an accidental misconfiguration in a
 remote part of the Internet affecting the global Internet there is
 also the potential for malice.  For example, it has been demonstrated
 by accident that multiple hour outages at a major institution can be
 caused by a laptop and a dial account if proper precautions are not
 taken.  The dial account need not be with the same provider used by
 the major institution.
 The potential for error is increased by the CIDR preference for more
 specific routes [8].  If an institution advertises a single route of
 a given length and a distant router advertises a more specific route
 covering critical hosts, the more specific route, if accepted at all,
 is preferred regardless of administrative weighting or any routing
 protocol attributes.
 There is a need to provide some form of checks on whether a route
 advertisement is valid.  Today checks are typically made against the
 border AS advertising the route.  This prevents accepting routes from
 the set of border AS that could not legitimately advertise the route.
 Theses checks rely on the use of information registered in the IRR to
 generate lists of prefixes that could be advertised by a specific
 border AS. Checks can also be made against the origin AS. If policy
 information were sufficiently populated, checks could be made against
 the entire AS path, but this is not yet feasible.

Villamizar, et al. Standards Track [Page 7] RFC 2725 Routing Policy System Security December 1999

 The use of a routing registry can also make it more difficult for
 prefixes to be used without authorization such as unallocated
 prefixes or prefixes allocated to another party.
 In summary, some of the problems being addressed are:
 o  Localizing the impact of accidental misconfiguration made by
    Internet Providers to that provider's networks only.
 o  Eliminating the potential for an Internet provider's customer to
    use malicious misconfiguration of routing as a denial of service
    attack if the provider route filters their customers.  Localizing
    the denial of service to that Internet provider only if the
    immediate Internet service provider does not route filter their
    customers but other providers route filter the route exchange at
    the interprovider peering.
 o  Eliminating the unauthorized use of address space.
 If the data within a routing registry is critical, then the ability
 to change the data must be controlled.  Centralized authorities can
 provide control but centralization can lead to scaling problems (and
 is politically distasteful).
 Address allocation and name allocation is already delegated.  Since
 delegation can be to outside registries it is at least somewhat
 distributed [11].  Autonomous System (AS) numbers are allocated by
 the same authorities.  It makes sense to delegate the routing number
 space in a manner similar to the address allocation and AS number
 allocation.  The need for this delegation of authority to numerous
 registries increases the difficulty of maintaining the integrity of
 the body of information as a whole.
 As a first step, the database can be somewhat centrally administered
 with authority granted to many parties to change the information.
 This is the case with the current IRR. There are a very small number
 of well trusted repositories and a very large number of parties
 authorized to make changes.  Control must be exercised over who can
 make changes and what changes they can make.  The distinction of who
 vs what separates authentication from authorization.
 o  Authentication is the means to determine who is attempting to make
    a change.
 o  Authorization is the determination of whether a transaction
    passing a specific authentication check is allowed to perform a
    given operation.

Villamizar, et al. Standards Track [Page 8] RFC 2725 Routing Policy System Security December 1999

 Different portions of the database will require different methods of
 authentication.  Some applications will require authentication based
 on strong encryption.  In other cases software supporting strong
 encryption may not be necessary or may not be legally available.  For
 this reason multiple authentication methods must be supported,
 selected on a per object basis through the specification of
 authentication methods in the maintainer object "auth" attribute.
 The authentication methods may range from very weak data integrity
 checks to cryptographicly strong signatures.  The authorization model
 must sure that the use of weak integrity checks in parts of the
 database does not compromise the overall integrity of the database.
 Additional requirements are placed on the authorization model if the
 database is widely distributed with delegations made to parties that
 may not be trustworthy or whose security practices may be lacking.
 This problem must be addressed in the authorization model in order to
 enable later evolution to a more distributed routing registry.
 Autonomous system numbers can be delegated in blocks and subdelegated
 as needed and then individual AS numbers assigned.  Address
 allocation is a simple numeric hierarchy.  Route allocation is
 somewhat more complicated.  The key attributes in a route object (key
 with regard to making it unique) contain both an address prefix and
 an AS number, known as the origin AS. The addition of a route object
 must be validated against the authorization criteria for both the AS
 and the address prefix.  Route objects may exist for the same prefix
 with multiple origin AS values due to a common multihoming practice
 that does not require a unique origin AS. There is often no
 correlation between the origin AS of a prefix and the origin AS of
 overlapping more specific prefixes.
 There are numerous operational cases that must be accommodated.  Some
 of the more common are listed below.  These are explored in greater
 detail in Appendix D with discussion of technical tradeoffs in
 Appendix C.
 o  simple hierarchical address allocation and route allocation
 o  aggregation and multihomed more specific routes
 o  provider independent addresses and multiple origin AS
 o  changing Internet service providers
 o  renumbering grace periods

Villamizar, et al. Standards Track [Page 9] RFC 2725 Routing Policy System Security December 1999

 The authorization model must accommodate a variety of policies
 regarding the allocation of address space and cannot mandate the use
 of any one model.  There is no standardization of address allocation
 policies though guidelines do exist [11, 16].  Whether authorization
 allows the recovery of address space must be selectable on a per
 object basis and may differ in parts of the database.  This issue is
 discussed further in Appendix C.

7 Data Representation

 RPSL provides a complete description of the contents of a routing
 repository [1].  Many RPSL data objects remain unchanged from the
 RIPE specifications and RPSL references the RIPE-181 specification as
 recorded in RFC-1786 [2].  RPSL provides external data
 representation.  Data may be stored differently internal to a routing
 registry.
 Some database object types or database attributes must be added to
 RPSL to record the delegation of authority and to improve the
 authentication and authorization mechanisms.  These additions are
 very few and are described in Section 8 and Section 9.
 Some form of encapsulation must be used to exchange data.  The
 defacto encapsulation has been the one which the RIPE tools accept, a
 plain text file or plain text in the body of an RFC-822 formatted
 mail message with information needed for authentication derived from
 the mail headers or the body of the message.  Merit has slightly
 modified this using the PGP signed portion of a plain text file or
 PGP signed portion of the body of a mail message.  These very simple
 forms of encapsulation are suitable for the initial submission of a
 database transaction.
 The encapsulation of registry transaction submissions, registry
 queries and registry responses and exchanges between registries is
 outside the scope of this document.  The encapsulation of registry
 transaction submissions and exchanges between registries is outside
 the scope of this document.

8 Authentication Model

 The maintainer objects serve as a container to hold authentication
 filters.  A reference to a maintainer within another object defines
 authorization to perform operations on the object or on a set of
 related objects.  The maintainer is typically referenced by name in
 mnt-by attributes of objects.  Further details on the use of
 maintainers are provided in Section 9.1.

Villamizar, et al. Standards Track [Page 10] RFC 2725 Routing Policy System Security December 1999

 The maintainer contains one or more "auth" attributes.  Each "auth"
 attribute begins with a keyword identifying the authentication method
 followed by the authentication information needed to enforce that
 method.  The PGPKEY method is slightly syntactically different in
 that the method PGPKEY is a substring.
 Authentication methods currently supported include the following.
 Note that pgp-from is being replaced by the pgpkey (see Section 10
 and [18]).
 mail-from  This is a very weak authentication check and is
    discouraged.  The authentication information is a regular
    expression over ASCII characters.  The maintainer is authenticated
    if the from or reply-to fields in RFC-822 mail headers are matched
    by this regular expression.  Since mail forgery is quite easy,
    this is a very weak form of authentication.
 crypt-pw  This is another weak form of authentication.  The
    authentication information is a fixed encrypted password in UNIX
    crypt format.  The maintainer is authenticated if the transaction
    contains the clear text password of the maintainer.  Since the
    password is in clear text in transactions, it can be captured by
    snooping.  Since the encrypted form of the password is exposed, it
    is subject to password guessing attacks.
 pgp-from  This format is being replaced by the "pgpkey" so that the
    public key certificate will be available to remote repositories.
    This is Merit's PGP extension.  The authentication information is
    a signature identity pointing to an external public key ring.  The
    maintainer is authenticated if the transaction (currently PGP
    signed portion of a mail message) is signed by the corresponding
    private key.
 pgpkey  This keyword takes the form "PGPKEY-hhhhhhhh", where
    "hhhhhhhh" is the hex representation of the four byte id of the
    PGP public key used for authentication.  The public key
    certificate is stored in a separate object as described in [18].
 Repositories may elect to disallow the addition of "auth" attributes
 specifying weaker forms of authentication and/or disallow their use
 in local transaction submissions.  Repositories are encouraged to
 disallow the addition of "auth" attributes with the deprecated "pgp-
 from" method.
 Any digital signature technique can in principle be used for
 authentication.  Transactions should be signed using multiple digital
 signature techniques to allow repositories or mirrors that only use a

Villamizar, et al. Standards Track [Page 11] RFC 2725 Routing Policy System Security December 1999

 subset of the techniques to verify at least one of the signatures.
 The selection of digital signature techniques is not within the scope
 of this document.

9 Authorization Model

 The authorization model must accommodate the requirements outlined in
 Section 6.  A key feature of the authorization model is the
 recognition that authorization for the addition of certain types of
 data objects must be derived from related data objects.
 With multiple repositories, objects not found in RPSL are needed to
 control AS delegations and new attributes are needed in existing
 objects to control subdelegation.  The definition of RPSL objects
 used to implement a distrubuted routing registry system is not within
 the scope of this document.

9.1 Maintainer Objects

 The maintainer objects serve as a container to hold authentication
 filters.  The authentication methods are described in Section 8.  The
 maintainer can be referenced by name in other objects, most notably
 in the mnt-by attributes of those objects.
 Maintainers themselves contain mnt-by attributes.  In some cases the
 mnt-by in a maintainer will reference the maintainer itself.  In this
 case, authorization to modify the maintainer is provided to a
 (usually very limited) set of identities.  A good practice is to
 create a maintainer containing a long list of identities authorized
 to make specific types of changes but have the maintainer's mnt-by
 attribute reference a far more restrictive maintainer more tightly
 controlling changes to the maintainer object itself.
 The mnt-by attribute is mandatory in all objects.  Some data already
 exists without mnt-by attributes.  A missing mnt-by attribute is
 interpreted as the absence of any control over changes.  This is
 highly inadvisable and most repositories will no longer allow this.
 An additional maintainer reference can occur through a new attribute,
 "mnt-routes", and is used in aut-num, inetnum and route objects.  The
 "mnt-routes" attribute is an extension to RPSL and is described in
 detail in Section 10.
 A mnt-routes attribute in an aut-num object allows addition of route
 objects with that AS number as the origin to the maintainers listed.
 A mnt-routes attribute in an inetnum object allows addition of route
 objects with exact matching or more specific prefixes.  A mnt-routes
 attribute in a route object allows addition of route objects with

Villamizar, et al. Standards Track [Page 12] RFC 2725 Routing Policy System Security December 1999

 exact matching or more specific prefixes.  A mnt-routes attribute
 does not allow changes to the aut-num, inetnum, or route object where
 it appears.  A mnt-routes may optionally be constrained to only apply
 to a subset of more specific routes.
 Where "mnt-routes" or "mnt-lower" are applicable, any maintainer
 referenced in the "mnt-by" still apply.  The set of applicable
 maintainers for whatever check is being made is the union of the
 "mnt-routes" or "mnt-lower" and the "mnt-by".  For example, when
 authorizing a route object software would look at "mnt-routes", if it
 does not exist, look at "mnt-lower", if that does not exist look at
 "mnt-by".

9.2 as-block and aut-num objects

 An "as-block" object is needed to delegate a range of AS numbers to a
 given repository.  This is needed for authorization and it is needed
 to avoid having to make an exhaustive search of all repositories to
 find a specific AS. This search would not be an issue now but would
 be if a more distributed routing repository is used.  Distributed
 registry issues are not within the scope of this document.
 The "as-block" object also makes it possible to separate AS number
 allocation from registration of AS routing policy.
    as-block:        AS1321 - AS1335
 The "aut-num" describes the routing policy for an AS and is critical
 for router configuration of that AS and for analysis performed by
 another AS. For the purpose of this document it is sufficient to
 consider the aut-num solely as a place holder identifying the
 existence of an AS and providing a means to associate authorization
 with that AS when adding "route" objects.
 The "as-block" object is proposed here solely as a means of recording
 the delegation of blocks of AS numbers to alternate registries and in
 doing so providing a means to direct queries and a means to support
 hierarchical authorization across multiple repositories.

9.3 inetnum objects

 The "inetnum" exists to support address allocation.  For external
 number registries, such as those using "[r]whoisd[++]" the "inet-num"
 can serve as a secondary record that is added when an address
 allocation is made in the authoritative database.  Such records could
 be added by a address registry such as ARIN as a courtesy to the
 corresponding routing registry.

Villamizar, et al. Standards Track [Page 13] RFC 2725 Routing Policy System Security December 1999

    inetnum:        193.0.0.0 - 193.0.0.255
    source:         IANA

9.4 route objects

 Currently there are a quite few route objects in more than one
 registry.  Quite a few are registered with an origin AS for which
 they have never been announced.  There is a legitimate reason to be
 in more than one origin AS.
 The "route" object is used to record routes which may appear in the
 global routing table.  Explicit support for aggregation is provided.
 Route objects exist both for the configuration of routing information
 filters used to isolate incidents of erroneous route announcements
 (Section 6) and to support network problem diagnosis.

9.5 reclaim and no-reclaim attributes

 A reclaim attribute is needed in as-block, inetnum and route objects.
 The reclaim attribute allows a control to be retained over more
 specific AS, IP address or route space by allowing modify and delete
 privileges regardless of the mnt-by in the object itself.
 The reclaim attribute provides the means to enforce address lending.
 It allows cleanup in cases where entities cease to exist or as a last
 presort means to correct errors such as parties locking themselves
 out of access to their own objects.  To specify all more specific
 objects the reclaim attribute value should be "ALL". To allow finer
 control a set of prefixes can be specified.
 A no-reclaim attribute can be used to provide explicit exceptions.  A
 reclaim attribute can only be added to an existing object if the
 addition of the reclaim attribute does not remove autonomy of
 existing more specific objects that are covered by the new reclaim
 attribute.
 1. A reclaim attribute can be added to an existing object if there
    are no existing exact matches or more specific objects overlapped
    by the new reclaim attribute, or
 2. if the submitter is listed in the maintainer pointed to by the
    mnt-by of the objects which are overlapped, or
 3. if any overlapped object is listed in a no-reclaim attribute in
    the object where the reclaim is being added.

Villamizar, et al. Standards Track [Page 14] RFC 2725 Routing Policy System Security December 1999

 Similarly, a submitter may delete a no-reclaim attribute from an
 object only when that submitter is the only maintainer listed in the
 mnt-by attributes of any overlapped objects.  If the submitter is not
 listed in any of the maintainers pointed to by the mnt-by attributes
 for one or more overlapped object, then the submitter is not
 permitted to delete the no-reclaim attribute.
 If neither a reclaim or no-reclaim attribute is present, then more
 specific objects of a given object cannot be modified by the
 maintainer of the less specified object unless the maintainer is also
 listed as a maintainer in the more specific object.  However, the
 addition of a new route or inetnum object must pass authentication of
 the largest less specific prefix as part of the authentication check
 described in Section 9.9.
 See Section 10 for a full description of the reclaim and no-reclaim
 attributes.

9.6 Other Objects

 Many of the RPSL ancillary objects have no natural hierarchy the way
 AS numbers, Internet addresses and routes do have a numeric
 hierarchy.  Some examples are "maintainers", "people" and "role"
 objects.  For these objects, lack of any hierarchy leads to two
 problems.
 1. There is no hierarchy that can be exploited to direct queries to
    alternate registries.  At some point the query strategy of
    searching all known registries becomes impractical.
 2. There is no hierarchy on which authorizations of additions can be
    based.
 The first problem can be addressed by considering the name space for
 each of the ancillary objects to be unique only within the local
 database and to use explicit references to an external repository
 where needed.  To specify an external repository reference, the
 object key is preceded by the name of the repository and the
 delimiter "::".  For example a NIC handle may take the form
 "RIPE::CO19".  Currently there is a desire to keep NIC handles unique
 so the naming convention of appending a dash and the repository name
 is used.  Prepending the repository name provides the unique name
 space since an object in the RIPE database referencing "CO19" would
 be interpreted as "RIPE::CO19" by default, but it would still be
 possible to query or reference "IANA::CO19".  There is no possibility
 of accidentally forgetting to adhere to the conventions when making
 an addition and the existing objects are accommodated, including
 cases where name conflicts have already occurred.

Villamizar, et al. Standards Track [Page 15] RFC 2725 Routing Policy System Security December 1999

 The second problem can be partially addressed by using a referral
 system for the addition of maintainers and requiring that any other
 object be submitted by a registered maintainer or by IANA.  The
 referral system would allow any existing maintainer to add another
 maintainer.  This can be used in parallel with the addition of other
 object types to support the maintenance of those objects.  For
 example, when adding a subdomain to the "domain" hierarchy (in the
 RIPE repository where domains are also handled), even when adding a
 new domain to a relatively flat domain such as "com", there is
 already a maintainer for the existing domain.  The existing
 maintainer can add the maintainer that will be needed for the new
 domain in addition to adding the new domain and giving the new
 maintainer the right to modify it.
 An organization gaining a presence on the Internet for the first time
 would be given a maintainer.  This maintainer may list a small number
 of very trusted employees that are authorized to modify the
 maintainer itself.  The organization itself can then add another
 maintainer listing a larger set of employees but listing the more
 restrictive maintainer in the mnt-by attributes of the maintainers
 themselves.  The organization can then add people and role objects as
 needed and any other objects as needed and as authorization permits.

9.7 Objects with AS Hierarchical Names

 Many RPSL objects do not have a natural hierarchy of their own but
 allow hierarchical names.  Some examples are the object types "as-
 set" and "route-set".  An as-set may have a name corresponding to no
 naming hierarchy such as "AS-Foo" or it may have a hierarchical name
 of the form "AS1:AS-Bar".
 When a hierarchical name is not used, authorization for objects such
 as "as-set" and "route-set" correspond to the rules for objects with
 no hierarchy described in Section 9.6.
 If hierarchical names are used, then the addition of an object must
 be authorized by the aut-num whose key is named by everything to the
 left of the rightmost colon in the name of the object being added.
 Authorization is determined by first using the mnt-lower maintainer
 reference, or if absent, using the mnt-by reference.

9.8 Query Processing

 A query may have to span multiple repositories.  All queries should
 be directed toward a local repository which may mirror the root
 repository and others.  Currently each IRR repository mirrors all
 other repositories.  In this way, the query may be answered by the
 local repository but draw data from others.

Villamizar, et al. Standards Track [Page 16] RFC 2725 Routing Policy System Security December 1999

 The mechanism below when applied to multiple repositories assumes the
 existence of an attribute for traversal of the repositories.  The
 definition of this attribute is considered a distributed registry
 issue and is out of scope of this document.
 For object types that have a natural hierarchy, such as aut-num,
 inet-num, and route, the search begins at the root database and
 follows the hierarchy.  For objects types that have no natural
 hierarchy, such as maintainer, person, and role objects, the search
 is confined to a default database unless a database is specified.
 The default database is the same database as an object from which a
 reference is made if the query is launched through the need to follow
 a reference. Otherwise the default is generally the local database or
 a default set by the repository.  The default can be specified in the
 query itself as described in Section 9.7.
 In the absense of attributes to traverse multiple registries a search
 of all repositories is needed.  With such attributes the search would
 proceed as follows.  In searching for an AS, the delegation attribute
 in AS blocks can be consulted, moving the search to data from other
 repositories.  Eventually the AS is either found or the search fails.
 The search for an inetnum is similar.  Less specific inetnums may
 refer the search to other databases.  Eventually the most specific
 inetnum is found and its status (assigned or not assigned) can be
 determined.  The definition of attributes for traversal of
 repositories is considered a distrbiuted registry issue and is not
 within the scope of this document.
 The search for a route in the presence of attributes for the
 traversal of multiple registries is similar except the search may
 branch to more than one repository.  The most specific route in one
 repository may be more specific than the most specific in another.
 In looking for a route object it makes sense to return the most
 specific route that is not more specific than the query requests
 regardless of which repository that route is in rather than return
 one route from each repository that contains a less specific overlap.

9.9 Adding to the Database

 The mechanism below when applied to multiple repositories assumes the
 existence of an attribute for traversal of the repositories.  The
 definition of this attribute is considered a distributed registry
 issue and is out of scope of this document.
 The root repository must be initially populated at some epoch with a
 few entries.  An initial maintainer is needed to add more
 maintainers.  The referral-by attribute can be set to refer to itself
 in this special case (Section 10 describes the referral-by).  When

Villamizar, et al. Standards Track [Page 17] RFC 2725 Routing Policy System Security December 1999

 adding an inetnum or a route object an existing exact match or a less
 specific overlap must exist.  A route object may be added based on an
 exact match or a less specific inetnum.  The root repository must be
 initially populated with the allocation of an inetnum covering the
 prefix 0/0, indicating that some address allocation authority exists.
 Similarly an initial as-block is needed covering the full AS number
 range.
 When adding an object with no natural hierarchy, the search for an
 existing object follows the procedure outlined in Section 9.8.
 When adding an aut-num (an AS), the same procedure used in a query is
 used to determine the appropriate repository for the addition and to
 determine which maintainer applies.  The sequence of AS-block objects
 and repository delegations is followed.  If the aut-num does not
 exist, then the submission must match the authentication specified in
 the maintainer for the most specific AS-block in order to be added.
 The procedure for adding an inetnum is similar.  The sequence of
 inet-num blocks is followed until the most specific is found.  The
 submission must match the authentication specified in the maintainer
 for the most specific inetnum overlapping the addition.
 Adding a route object is somewhat more complicated.  The route object
 submission must satisfy two authentication criteria.  It must match
 the authentication specified in the aut-num and the authentication
 specified in either a route object or if no applicable route object
 is found, then an inetnum.
 An addition is submitted with an AS number and prefix as its key.  If
 the object already exists, then the submission is treated as a modify
 (see Section 9.10).  If the aut-num does not exist on a route add,
 then the addition is rejected (see Section C for further discussion
 of tradeoffs).  If the aut-num exists then the submission is checked
 against the applicable maintainer.  A search is then done for the
 prefix first looking for an exact match.  If the search for an exact
 match fails, a search is made for the longest prefix match that is
 less specific than the prefix specified.  If this search succeeds it
 will return one or more route objects.  The submission must match an
 applicable maintainer in at least one of these route objects for the
 addition to succeed.  If the search for a route object fails, then a
 search is performed for an inetnum that exactly matches the prefix or
 for the most specific inetnum that is less specific than the route
 object submission.  The search for an inetnum should never fail but
 it may return an unallocated or reserved range.  The inetnum status
 must be "allocated" and the submission must match the maintainer.

Villamizar, et al. Standards Track [Page 18] RFC 2725 Routing Policy System Security December 1999

 Having found the AS and either a route object or inetnum, the
 authorization is taken from these two objects.  The applicable
 maintainer object is any referenced by the mnt-routes attributes.  If
 one or more mnt-routes attributes are present in an object, the mnt-
 by attributes are not considered.  In the absence of a mnt-routes
 attribute in a given object, the mnt-by attributes are used for that
 object.  The authentication must match one of the authorizations in
 each of the two objects.
 If the addition of a route object or inetnum contains a reclaim
 attribute, then any more specific objects of the same type must be
 examined.  The reclaim attribute can only be added if there are no
 more specific overlaps or if the authentication on the addition is
 present in the authorization of a less specific object that already
 has a reclaim attribute covering the prefix range, or if the
 authentication on the addition is authorized for the modification of
 all existing more specific prefixes covered by the addition.

9.10 Modifying or Deleting Database Objects

 When modifying or deleting any existing object a search for the
 object is performed as described in Section 9.8.  If the submission
 matches an applicable maintainer for the object, then the operation
 can proceed.  An applicable maintainer for a modification is any
 maintainer referenced by the mnt-by attribute in the object.  For
 route and inet-num objects an applicable maintainer may be listed in
 a less specific object with a reclaim attribute.
 If the submission is for a route object, a search is done for all
 less specific route objects and inetnums.  If the submission is for
 an inetnum, a search is done for all less specific inetnums.  If the
 submission fails the authorization in the object itself but matches
 the reclaim attribute in any of the less specific objects, then the
 operation can proceed.  Section C contains discussion of the
 rationale behind the use of the reclaim attribute.
 A modification to an inetnum object that adds a reclaim attribute or
 removes a no-reclaim attribute must be checked against all existing
 inetnums that are more specific.  The same check of the reclaim
 attribute that is made during addition must be made when a reclaim
 attribute is added by a modification (see Section 9.9).
 A deletion is considered a special case of the modify operation.  The
 deleted object may remain in the database with a "deleted" attribute
 in which case the mnt-by can still be consulted to remove the
 "deleted" attribute.

Villamizar, et al. Standards Track [Page 19] RFC 2725 Routing Policy System Security December 1999

10 Data Format Summaries

 RIPE-181 [2] and RPSL [1] data is represented externally as ASCII
 text.  Objects consist of a set of attributes.  Attributes are name
 value pairs.  A single attribute is represented as a single line with
 the name followed by a colon followed by whitespace characters
 (space, tab, or line continuation) and followed by the value.  Within
 a value all whitespace is equivalent to a single space.  Line
 continuation is supported by a backslash at the end of a line or the
 following line beginning with whitespace.  When transferred,
 externally attributes are generally broken into shorter lines using
 line continuation though this is not a requirement.  An object is
 externally represented as a series of attributes.  Objects are
 separated by blank lines.
 There are about 80 attribute types in the current RIPE schema and
 about 15 object types.  Some of the attributes are mandatory in
 certain objects.  Some attributes may appear multiple times.  One or
 more attributes may form a key.  Some attributes or sets of
 attributes may be required to be unique across all repositories.
 Some of the attributes may reference a key field in an object type
 and may be required to be a valid reference.  Some attributes may be
 used in inverse lookups.
 A review of the entire RIPE or RPSL schema would be too lengthy to
 include here.  Only the differences in the schema are described.

10.1 Changes to the RIPE/RPSL Schema

 One new object type and several attributes are added to the RIPE/RPSL
 schema.  There are significant changes to the rules which determine
 if the addition of an object is authorized.
 The new object type is listed below.  The first attribute listed is
 the key attribute and also serves as the name of the object type.
 as-block        key  mandatory  single    unique
 descr                optional   multiple
 remarks              optional   multiple
 admin-c              mandatory  multiple
 tech-c               mandatory  multiple
 notify               optional   multiple
 mnt-by               mandatory  multiple
 changed              mandatory  multiple
 source               mandatory  single

Villamizar, et al. Standards Track [Page 20] RFC 2725 Routing Policy System Security December 1999

 In the above object type only the key attribute "as-block" is new:
 as-block  This attribute provides the AS number range for an "as-
    block" object.  The format is two AS numbers including the sub-
    string "AS" separated by a "-" delimiter and optional whitespace
    before and after the delimiter.
 In order to support stronger authentication, the following keywords
 are added to the "auth" attribute:
 pgp-from  The remainder of the attribute gives the string identifying
    a PGP identity whose public key is held in an external keyring.
    The use of this method is deprecated in favor of the "pgpkey"
    method.
 pgpkey  See [18].
 In order to disable authentication and give permission to anyone, the
 authentication method "none" is added.  It has no arguments.
 An additional change is the "auth" attribute is allowed to exist in a
 "person" or "role" object.  The "auth" method "role" or "person" can
 be used to refer to a role or person object and take the "auth"
 fields from those objects.  Care must be taken in implementations to
 detect circular references and terminate expansion or the references
 already visited.
 A few attributes are added to the schema.  These are:
 mnt-routes  The mnt-routes attribute may appear in an aut-num, inet-
    num, or route object.  This attribute references a maintainer
    object which is used in determining authorization for the addition
    of route objects.  After the reference to the maintainer, an
    optional list of prefix ranges (as defined in RPSL) inside of
    curly braces or the keyword "ANY" may follow.  The default, when
    no additional set items are specified is "ANY" or all more
    specifics.  The mnt-routes attribute is optional and multiple.
    See usage details in Section 9.1.
 mnt-lower  The mnt-lower attribute may appear in an inetnum, route,
    as-block or aut-num object.  This attribute references a
    maintainer object.  When used in an inetnum or route object the
    effect is the same as a "mnt-routes" but applies only to prefixes
    more specific than the prefix of the object in which it is
    contained.  In an as block object, mnt-lower allows addition of
    more specific as-block objects or aut-num objects.  In an aut-num

Villamizar, et al. Standards Track [Page 21] RFC 2725 Routing Policy System Security December 1999

    object the mnt-lower attribute specifies a maintainer that can be
    used to add objects with hierarchical names as described in
    Section 9.7.
 reclaim  The reclaim attribute may appear in as-block, aut-num,
    inet-num, or route objects.  Any object of the same type below in
    the hierarchy may be modified or deleted by the maintainer of the
    object containing a reclaim attribute.  The value of the attribute
    is a set or range of objects of the same type where the syntax of
    the set or range is as defined in RPSL. See Section 9.5 for
    restrictions on adding reclaim attributes.
 no-reclaim  The no-reclaim attribute is used with the reclaim
    attribute.  The no-reclaim attribute negates any reclaim attribute
    it overlaps.  See Section 9.5 for restrictions on deleting no-
    reclaim attributes.
 referral-by  This attribute is required in the maintainer object.  It
    may never be altered after the addition of the maintainer.  This
    attribute refers to the maintainer that created this maintainer.
    It may be multiple if more than one signature appeared on the
    transaction creating the object.
 auth-override  An auth-override attribute can be added, deleted, or
    changed by a transaction submitted by maintainer listed in the
    referral-by.  An auth-override can only be added to a maintainer
    if that maintainer has been inactive for the prior 60 days.  The
    auth-override attribute itself contains only the date when the
    attribute will go into effect which must be at least 60 days from
    the current date unless there is already authorization to modify
    the maintainer.  After the date in the auth-override is reached,
    those identified by the maintainer in the referral-by have
    authorization to modify the maintainer.  This attribute exists as
    a means to clean up should the holder of a maintainer become
    unresponsive and can only take effect if that maintainer does not
    remove the auth-override in response to the automatic notification
    that occurs on changes.
 The existing "mnt-by" attribute references the "maintainer" object
 type.  The "mnt-by" attribute is now mandatory in all object types.
 A new maintainer may be added by any existing maintainer.  The
 "referral-by" attribute is now mandatory in the "maintainer" object
 to keep a record of which maintainer made the addition and can never
 be changed.  Maintainers cannot be deleted as long as they are
 referenced by a "referral-by" attribute elsewhere.

Villamizar, et al. Standards Track [Page 22] RFC 2725 Routing Policy System Security December 1999

A Core and Non-Core Functionality

 Most of the objects and attributes described in this document are
 essential to the authorization framework.  These are referred to as
 being part of the "core" functionality.  A few attributes listed here
 are considered "non-core".
 The "reclaim" and "no-reclaim" attributes are a convenience to
 support flexibility in the implementation of address lending.
 The "auth-override" attribute is a convenience to facilitate recovery
 in an environment where repository data is redistributed in any way.
 The "referal-by" attribute is a "core" feature.  An individual
 registry may express its sutonomy by creating a self-referencing
 maintainer, one whose "referal-by" points to itslef.  Other
 registries can decide on a case by case basis whether to consider
 such an entry valid.  A registry may only allow the "referal-by" to
 refer to a specific maintainer under the control of the registry.
 This further restriction is an issue that is purely local to the
 registry.

B Examples

 The examples below leave out some required attributes that are not
 needed to illustrate the use of the objects and attributes described
 in this document.  Missing are admin-c, tech-c, changed, source.
 Also missing are attributes such as mnt-nfy, whose use are a good
 practice but are not strictly required.
 To do anything at all a maintainer is needed.  At some epoch a a
 single maintainer is populated in one repository and that maintianer
 has a referal-by pointing to itself.  All others referal-by
 references can be traced back to that maintainer.  At the epoch the
 as-block AS0- AS65535 and the inetnum 0.0.0.0-255.255.255.255 are
 also allocated.  Other ancilliary object may also be needed to
 bootstrap.
    mntner:        ROOT-MAINTAINER
    auth:          pgpkey-12345678
    mnt-by:        ROOT-MAINTAINER
    referal-by:    ROOT-MAINTAINER
 This root maintainer might add a top level maintainer for some
 organization.

Villamizar, et al. Standards Track [Page 23] RFC 2725 Routing Policy System Security December 1999

    mntner:        WIZARDS
    descr:         High level Technical Folks
    auth:          pgpkey-23456789
    auth:          pgpkey-3456789a
    mnt-by:        WIZARDS
    referal-by:    ROOT-MAINTAINER
 That maintainer might add another who have more limited capabilities.
    mntner:        MORTALS
    descr:         Maintain day to day operations
    auth:          pgpkey-456789ab
    auth:          pgpkey-56789abc
    auth:          pgpkey-6789abcd
    mnt-by:        WIZARDS
    referal-by:    WIZARDS
 Note that the WIZARDS can change their own maintainer object and the
 MORTALS maintainer object but MORTALS cannot.
 At some point an as-block is allocated and broken down.  In the
 example below, private number space is used.
    as-block:      AS65500-AS65510
    mnt-by:        SOME-REGISTRY
    mnt-lower:     WIZARDS
    Note that a registry has control over the object that they have
    created representing the allocation, but have given the party to
    which the allocation was made the ability to create more specific
    objects. Below this as-block, an aut-num is added.  Note that
    import and export are normally required for a aut-num but are not
    shown here.
    aut-num:       AS65501
    mnt-by:        WIZARDS
    mnt-lower:     MORTALS
 In aut-num above the WIZARDS maintainer can modify the aut-num
 itself.  The MORTALS maintainer can add route objects using this AS
 as the origin if they also have authorization for the IP number space
 in a less specific route or inetnum.

Villamizar, et al. Standards Track [Page 24] RFC 2725 Routing Policy System Security December 1999

 We also need an inetnum allocation.  In this example the inetnum is
 allocated to a completely different organization.  Again attributes
 are omited which would normally be needed in an inetnum.
    inetnum:       192.168.144.0-192.168.151.255
    mnt-by:        SOME-REGISTRY
    mnt-lower:     ISP
    reclaim:       ALL
 The maintainer ISP can add more specific inetnums or routes with this
 address space.  Note that the registry has declared their ability to
 reclaim the address space.
 If ISP wished to reclaim all allocations but some suballocation of
 theirs resisted, we might get something like the following in which
 they will reclaim only the top half of an allocation (possibly if it
 remains unused).
    inetnum:       192.168.144.0-192.168.147.255
    mnt-by:        ISP
    mnt-lower:     EBG-COM
    reclaim:       192.168.146/23+
 If we assume that the maintainer EBG-COM and the maintainer MORTALS
 want to add a route object, one way to do it is for both parties to
 sign.  If EBG-COM for some reason couldn't aggregate an allocate a
 single top level route (which is inexcusable these days) or there was
 a preference for some reason to avoid the joint signature approach on
 a submission either party could give the other permission to make the
 addition.  A mnt-routes could be added to the aut-num or a mnt-lower
 could be added to an inetnum.
    aut-num:       AS65501
    mnt-by:        WIZARDS
    mnt-lower:     MORTALS
    mnt-routes:    EBG-COM {192.168.144/23}
 With this change to the aut-num the maintainer EBG-COM could add a
 route with origin AS65501, but only with a limited address range.
    route:         192.168.144/24
    origin:        AS65501
    descr:         These boneheads don't aggregate
    mnt-by:        EBG-COM
    mnt-by:        FICTION::MORTALS
 Note that while the maintainer EBG-COM added the object they allowed
 the maintainer MORTALS the ability to modify it.

Villamizar, et al. Standards Track [Page 25] RFC 2725 Routing Policy System Security December 1999

 If an object ended up in another repository, a single maintainer
 could still be used.  In the example above the notation
 FICTION::MORTALS indicates that the route object is in a different
 repository and rather than duplicate the maintainer, a reference is
 made to the repository in which the MORTALS object resides.
 In the example below, a pair of route-sets are added and hierarchical
 names are used.
    route-set:     AS65501:Customers
    mnt-by:        WIZARDS
    mnt-lower:     MORTALS
    route-set:     AS65501:Customers:EBG-COM
    mnt-by:        MORTALS
    mnt-lower:     EBG-COM
 Suppose in the 192.168.144/24 object above, only the EBG-COM
 maintainer is listed.  If EBG-COM goes bankrupt, no longer needs
 address space, and stops responding, it could be difficult to delete
 this object.  The maintainer listed in the EBG-COM referral-by
 attribute could be contacted.  They could add a auth-override
 attribute to the EBG-COM object.  Later they could modify the EBG-COM
 object and then any objects with EBG-COM in the mnt-by.
    mntner:        EBG-COM
    mnt-by:        EBG-COM
    auth-override: 19990401
 The examples above stray significantly from realism.  They do provide
 simple illustrations of the usage of the objects type and attributes
 described in this document and hopefully in doing some are of some
 value.

C Technical Discussion

 A few design tradeoffs exist.  Some of these tradeoffs, the selected
 solution, and the alternatives are discussed here.  Some of the
 issues are listed below.
 1. Whether to err on the side of permissiveness and weaken
    authorization controls or risk the possibility of erecting
    barriers to registering information.
 2. Whether to support enforcible address lending or provide the
    smaller or end user with ultimate control over the registration of
    the prefixes they are using.

Villamizar, et al. Standards Track [Page 26] RFC 2725 Routing Policy System Security December 1999

 3. What to do with older objects that either don't conform to newer
    requirements regarding minimum authorization, authentication, and
    accountability, or are of questionable validity.

C.1 Relaxing requirements for ease of registry

 If the requirement that an aut-num exists is relaxed, then it is
 possible for anyone to make use of an unassigned AS number or make
 use of an assigned AS number for which the aut-num has not been
 entered.  Placing requirements on the entry of aut-num presumes
 cooperation of the Internet address allocation authority (if separate
 from the routing registry).  The address allocation authority must be
 willing to field requests to populate skeleton aut-nums from the
 party for which the allocation has been made.  These aut-num must
 include a reference to a maintainer.  A request to the address
 allocation authority must therefore include a reference to an
 existing maintainer.
 The ability to add route objects is also tied to the existence of
 less specific route objects or inetnums.  The Internet address
 allocation authority (if separate from the routing registry) must
 also be willing to field requests to add inetnum records for the
 party already allocated the address space.
 The Internet address allocation authority should also add inetnums
 and aut-nums for new allocations.  In order to do so, a maintainer
 must exist.  If a party is going to connect to the Internet, they can
 get a maintainer by making a request to the Internet service provider
 they will be connecting to.  Once they have a maintainer they can
 make a request for address space or an AS number.  The maintainer can
 contain a public key for a cryptographicly strong authorization
 method or could contain a "crypt-key" or "mail-to" authorization
 check if that is considered adequate by the registering party.
 Furthermore an address allocation authority should verify that the
 request for an AS number or for address space matches the
 authorization criteria in the maintainer.
 Currently only the registries themselves may add maintainers.  This
 becomes a problem for the registry, particularly in verifying public
 keys.  This requirement is relaxed by allowing existing maintainers
 to add maintainers.  Unfortunately the accountability trail does not
 exist for existing maintainers.  The requirement then should be
 relaxed such that existing maintainers may remain but only existing
 maintainers that have a "referral-by" attribute can add maintainers.
 The "referral-by" cannot be modified.  This requirement can be
 relaxed slightly so that a "referral-by" can be added to a maintainer

Villamizar, et al. Standards Track [Page 27] RFC 2725 Routing Policy System Security December 1999

 by an existing maintainer with a "referral-by".  This will allow the
 accountability trail to be added to existing maintainers and these
 maintainers can then add new maintainers.
 Verifying that a party is who they claim to be on initial addition,
 is one of the problems that currently falls upon the AS number and
 address registry.  This problem is reduced by allowing existing
 maintainers to add maintainers.  This may actually make it easier to
 get maintainers and therefore easier to register.  The number
 authority still must verify that the AS or address space is actually
 needed by the party making a request.
 Authorization checks made during the addition of route objects that
 refer to AS objects and inetnums strongly rely on the cooperation of
 the Internet address allocation authorities.  The number authorities
 must register as-blocks, aut-nums, or inetnums as AS numbers or
 address space is allocated.  If only a subset of the number
 authorities cooperate, then either an inetnum or as-block can be
 created covering the space that registry allocates and essentially
 requiring null allocation (for example a "crypt-pw" authentication
 where the password is given in the remarks in the object or its
 maintainer) or those obtaining addresses from that number authority
 will have trouble registering in the routing registry.  The
 authorization model supports either option, though it would be
 preferable if the number authorities cooperated and the issue never
 surfaced in practice.
 The maintainer requirements can be relaxed slightly for existing
 maintainers making it easier to register.  Relaxing requirements on
 other objects may defeat the authorization model, hence is not an
 option.

C.2 The address lending issue

 The issue of whether lending contracts should be enforcible is an
 issue of who should ultimately be able to exercise control over
 allocations of address space.  The routing registry would be wise to
 stay as neutral as possible with regard to disputes between third
 parties.  The "reclaim" and "no-reclaim" are designed to allow either
 outcome to the decision as to whether the holder of a less specific
 inetnum or route object can exercise control over suballocations in
 the registry.  The routing registry itself must decide whether to
 retain control themselves and if so, should very clearly state under
 what conditions the registry would intervene.  A registry could even
 go to the extreme of stating that they will intervene in such a
 dispute only after the dispute has been resolved in court and a court
 order has been issued.

Villamizar, et al. Standards Track [Page 28] RFC 2725 Routing Policy System Security December 1999

 When an allocation is made by a registry, the registry should keep a
 "reclaim" attribute in the less specific object and make a strong
 policy statement that the reclaim privilege will not be used except
 under very clearly defined special circumstances (which at the very
 minimum would include a court order).  If the allocation is further
 subdivided the party subdividing the allocation and the party
 accepting the suballocation must decide whether a "reclaim" can be
 kept by the holder of the less specific allocation or whether a "no-
 reclaim" must be added transferring control to the holder of the more
 specific.  The registry is not involved in that decision.  Different
 pairs of third parties may reach different decisions regarding the
 "reclaim" and any contractual restrictions on its use that may be
 expressed outside of the registry in the form of a legal contract and
 ultimately resolved by the courts in the event of a bitter dispute.
 By retaining "reclaim" rights the registry retains the ability to
 abide by a court order.  This may only truly become an issue in a
 distributed registry environment where registries will be rechecking
 the authorization of transactions made elsewhere and may fail to
 process the attempt of another registry to abide by a court order by
 overriding normal authorization to change the registry contents if a
 reclaim is not present.

C.3 Dealing with non-conformant or questionable older data

 Some of the newer requirements include requiring that all objects
 reference a maintainer object responsible for the integrity of the
 object and requiring accountability for the creation of maintainers
 to be recorded in the maintainer objects so that accountability can
 be traced back from an unresponsive maintainer.  In the event that
 contact information is absent or incorrect from objects and there is
 any question regarding the validity of the objects, the maintainer
 can be contacted.  If the maintainer is unresponsive, the maintainer
 that authorized the addition of that maintainer can be contacted to
 either update the contact information on the maintainer or confirm
 that the entity no longer exists or is no longer actively using the
 Internet or the registry.
 Many route objects exist for which there are no maintainers and for
 which inetnum and AS objects do not exist.  Some contain the now
 obsoleted guardian attribute rather than a mnt-by.
 It is not practical to unconditionally purge old data that does not
 have maintainers or does not conform to the authorization hierarchy.
 New additions must be required to conform to the new requirements
 (otherwise the requirements are meaningless).  New requirements can
 be phased in by requiring modifications to conform to the new
 requirements.

Villamizar, et al. Standards Track [Page 29] RFC 2725 Routing Policy System Security December 1999

 A great deal of questionable data exists in the current registry.
 The requirement that all objects have maintainers and the
 requirements for improved accountability in the maintainers
 themselves may make it easier to determine contact information even
 where the objects are not updated to reflect contact information
 changes.
 It is not unreasonable to require valid contact information on
 existing data.  A great deal of data appears to be unused, such as
 route objects for which no announcement has been seen in many months
 or years.  An attempt should be made to contact the listed contacts
 in the object, in the maintainer if there is one, then up the
 maintainer referral-by chain if there is one, and using the number
 registry or origin AS contact information if there is no maintainer
 accountability trail to follow.  Experience so far indicates that the
 vast majority of deletions identified by comparing registered
 prefixes against route dumps will be positively confirmed (allowing
 the deletion) or there will be no response due to invalid contact
 information (in many cases the IRR contact information points to
 nsfnet-admin@merit.edu).
 By allowing the registry to modify (or delete) any objects which are
 disconnected from the maintainer accountability trail, cleanup can be
 made possible (though mail header forging could in many cases have
 the same effect it is preferable to record the fact that the registry
 itself made the cleanup).  Similarly, a mechanism may be needed in
 the future to allow the maintainer in the referral-by to override
 maintainer privileges in a referred maintainer if all contacts have
 become unresponsive for a maintainer.  The referral-by maintainer is
 allowed to add an "auth-override" attribute which becomes usable as
 an "auth" within 60 days from the time of addition.  The maintainer
 themselves would be notified of the change and could remove the
 "auth-override" attribute before it becomes effective and inquire as
 to why it was added and correct whatever problem existed.  This can
 be supported immediately or added later if needed.

D Common Operational Cases

 In principle, address allocation and route allocation should be
 hierarchical with the hierarchy corresponding to the physical
 topology.  In practice, this is often not the case for numerous
 reasons.  The primary reasons are the topology is not strictly tree
 structured and the topology can change.  More specificly:

Villamizar, et al. Standards Track [Page 30] RFC 2725 Routing Policy System Security December 1999

 1. The Internet topology is not strictly tree structured.
    o  At the top level the network more closely resembles a
       moderately dense mesh.
    o  Near the bottom level many attachments to the Internet are
       multi-homed to more than one Internet provider.
 2. The Internet topology can and does change.
    o  Many attachments switch providers to obtain better service or
       terms.
    o  Service providers may modify adjacencies to obtain better
       transit service or terms.
    o  Service providers may disappear completely scattering
       attachments or they may merge.
 Renumbering is viewed as a practical means to maintain a strict
 numeric hierarchy [16].  It is also acknowledged that renumbering
 IPv4 networks can be difficult [16, 3, 17].  We examine first the
 simple case where hierarchy still exists.  We then examine the
 operational cases where either initial topology is not tree
 structured or cases where topology changes.

D.1 simple hierarchical address allocation and route allocation

 This is the simplest case.  Large ranges of inetnums are assigned to
 address registries.  These registries in turn assign smaller ranges
 for direct use or to topologically large entities where allocations
 according to topology can reduce the amount of routing information
 needed (promote better route aggregation).
 AS objects are allocated as topology dictates the need for additional
 AS [10].  Route objects can be registered by those with authorization
 given by the AS and by the address owner.  This is never an issue
 where the maintainer of the AS and the inetnum are the same.  Where
 they differ, either the provider can give permission to add route
 objects for their AS, or the party allocated the address space can
 give the provider permission to add route objects for their address
 space, or both parties can sign the transaction.  Permission is
 provided by adding to maintainer attributes.

Villamizar, et al. Standards Track [Page 31] RFC 2725 Routing Policy System Security December 1999

D.2 aggregation and multihomed more specific routes

 Aggregation is normally not a problem if a provider is aggregating
 address space allocated to the provider and then suballocated
 internally and/or to customers.  In fact, the provider would be
 expected to do so.  This is not a problem even if the route object
 for the aggregation is added after the more specific route objects
 since only less specific objects are considered.
 Aggregation is potentially a problem if a provider or a set of
 providers plan to aggregate address space that was never explicitly
 allocated as a block to those providers but rather remains the
 allocation of a address registry.  These large aggregations can be
 expected to be uncommon, but relatively easily dealt with.
 Superaggregates of this type will generally be formed by
 topologically close entities who have also managed to draw adjacent
 address allocations.  In effect, the registry must give permission to
 form such a superaggregate by either giving permission to do so in
 the mnt-routes of an inetnum or by signing the submission along with
 the other parties.

D.3 provider independent addresses and multiple origin AS

 Provider independent addresses and multihoming arrangement using
 multiple origin AS present a similar problem to multihoming.  The
 maintainer of the address space and the maintainer of the AS is not
 the same.  Permission can be granted using mnt-routes or multiple
 signatures can appear on the submission.

D.4 change in Internet service provider

 A change in Internet service providers is similar to multihoming.  A
 minor difference is that the AS for the more specific route will be
 the AS of the new provider rather than the AS of the multihomed
 customer.  Permission can be granted using mnt-routes or multiple
 signatures can appear on the submission.

D.5 renumbering grace periods

 Renumbering grace periods allow a provider who wants to keep an
 address allocation intact to allow a customer who has chosen to go to
 another provider to renumber their network gradually and then return
 the address space after renumbering is completed.  The issue of
 whether to require immediate renumbering or offer renumbering grace
 periods and how long they should be or whether they should be
 indefinite has been topic of bitter disputes.  The authorization
 model can support no renumbering grace period, a finite renumbering

Villamizar, et al. Standards Track [Page 32] RFC 2725 Routing Policy System Security December 1999

 grace period, or an indefinite renumbering grace period.  The
 "reclaim" attribute described in Section 9.1 provides a means to end
 the grace period.

E Deployment Considerations

 This section describes deployment considerations.  The intention is
 to raise issues and discuss approaches rather than to provide a
 deployment plan.
 The use of routing registries is not yet universally accepted.  There
 still remain Internet providers who see no reason to provide the
 added assurance of accurate routing information described in Section
 6.  More accurately, these benefits are viewed as being insufficient
 to justify the cost.  This has been largely caused an inability of a
 very major router vendor up until recently to handle prefix lists of
 the size needed to specify routing policy on a per prefix basis.
 Another reason cited is that filtering on a prefix basis in an
 environment where routing registry information is incomplete or
 inaccurate can interfere with connectivity.
 There clearly is a critical mass issue with regard to the use of
 routing registries.  A minority of providers use the existing IRR to
 filter on a per prefix basis.  Another minority of providers do not
 support the IRR and generally fail to register prefixes until
 connectivity problems are reported.  The majority of providers
 register prefixes but do not implement strict prefix filtering.
 Deploying new authentication mechanisms has no adverse consequences.
 This has been proven with Merit's deployment of PGP.
 In deploying new authorization mechanisms, a major issue is dealing
 with existing data of very questionable origin.  A very large number
 of route objects refer to prefixes that have not been announced for
 many years.  Other route objects refer to prefixes that are no longer
 announced with the origin AS that they are registered with (some were
 incorrectly registered to start with).  There are many causes for
 this.
 1. During the transition from the NSFNET PRDB to the RADB a large
    number of prefixes were registered with an origin AS corresponding
    to the border AS at which the NSFNET had once heard the route
    announcements.  The PRDB did not support origin AS, so border AS
    was used.  Many of these routes were no longer in use at the time
    and are now routed with a submitter listed as "nsfnet-
    admin@merit.edu".

Villamizar, et al. Standards Track [Page 33] RFC 2725 Routing Policy System Security December 1999

 2. As CIDR was deployed, aggregates replaced previously separately
    announced more specific prefixes.  The route objects for the more
    specific prefixes were never withdrawn from the routing
    registries.
 3. Some prefixes are simply no longer in use.  Some networks have
    been renumbered.  Some network no longer exist.  Often the routing
    registry information is not withdrawn.
 4. As provider AS adjacencies changed and as end customers switched
    providers often the actual origin AS changed.  This was often not
    reflected by a change in the routing registry.
 Inaccuracies will continue to occur due to the reasons above, except
 the first.  The hierarchical authorization provides greater
 accountability.  In the event that the contacts for specific objects
 become unresponsive traversal up the authorization hierarchy should
 help identify the parties having previous provided authorization.
 These contacts may still have sufficient authorization to perform the
 necessary cleanup.  This issue is discussed in Section C.
 A great deal of information is currently missing in the IRR. Quite a
 few AS have no aut-num.  Quite a lot of data has no maintainer and
 the vast majority of maintainers use only the weakest of
 authentication methods.  Very little can be done by the registries to
 correct this.  The defaults in the cases of missing objects needed
 for authorization has to be to make no authentication checks at all.
 The transition can be staged as follows:
 1. Add and make use of stronger authorization models.
 2. Make schema modifications necessary to support delegations.
 3. Add delegation attributes needed for query traversal.
 4. Base query traversal on delegations rather than a search of all
    known registries.
 5. Obtain the cooperation of the address registries for the purpose
    of populating the "inetnum" entries on an ongoing basis.
 6. Add hierarchical authorization support for critical object types,
    "aut-num", "inetnum" and "route".
 7. Add the requirement that database object either be in use or have
    valid contact information and if queries are made by the registry
    a response from a contact indicating that the object serves a
    purpose if it is not clear what its use is.

Villamizar, et al. Standards Track [Page 34] RFC 2725 Routing Policy System Security December 1999

 8. Begin to purge data which is clearly not in use and for which
    there is no valid contact information or no response from the
    contacts.
 Deployment of hierarchical authorization requires cooperation among
 the existing routing registries.  New code will have to be deployed.
 In some cases minimal development resources are available and
 substantial inertia exists due to the reliance on the current
 repository and the need to avoid disruption.
 If hierarchical authorization of route objects depends on the
 existence of address registration information, minimal cooperation of
 the currently separate address registries is required.  The extent of
 the cooperation amounts to sending cryptographically signed
 transactions from the address registry to the number registry as
 address allocations are made or providing equivalent access to new
 address allocations.
 Currently most registries return query results from all of the known
 repositories using their mirrored copies.  Cross registry
 authorizations are not yet implemented.  Minimal schema changes have
 to be made to support the ability to delegate objects for which there
 is an authorization hierarchy and to support queries and references
 to other repositories.  In the case of AS delegations, "as-block"
 need to be created solely for the purpose of traversal.

F Route Object Authorization Pseudocode

 The following list provides a brief review of basic concepts.
 1. The route object submission must satisfy two authentication
    criteria.  It must match the authentication specified in the aut-
    num and the authentication specified in either a route object or
    if no applicable route object is found, then an inetnum.
 2. When checking for prefix authorization, an exact route object
    prefix match is checked for first.  If there is not an exact match
    then a longest prefix match that is less specific than the prefix
    is searched for.  If the route prefix search fails, then a search
    is performed for an inetnum that exactly matches the prefix or for
    the most specific inetnum that is less specific than the route
    object submission.
    The search for an inetnum should never fail but it may return an
    unallocated or reserved range.  The inetnum status must be
    "allocated" and the submission must pass it's maintainer

Villamizar, et al. Standards Track [Page 35] RFC 2725 Routing Policy System Security December 1999

    authorization in order to get authorization from an inetnum.  So
    an unallocated or reserved range inetnum will cause the route
    object submission to fail.
 3. A route object must pass authorization from both the referenced
    aut-num object and the route or inetnum object.  Authorization
    shall be tested using the maintainer(s) referenced in the "mnt-
    routes" attribute(s) first.  If that check fails, the "mnt-lower"
    attributes are checked.  If that check fails the "mnt-by"
    attributes are used for the authorization check.
 4. The "reclaim" attribute can appear in inetnum, route and as-block
    objects and provides a means to support address lending. "reclaim"
    gives authorization over more specific objects, regardless of the
    "mnt-by" in the object.  The value of a "reclaim" attribute can be
    a list or set of objects to provide finer grain control.
    The "reclaim" attribute is important to this discussion since it
    affects prefix/origin authentication when a new route object is
    submitted.
    The "no-reclaim" attribute is used to provide explicit exceptions.
 The following pseudocode outlines the algorithm used to check for
 proper authorization of a route object submission.
  Case #1.  Route object add
            (ie, no exact prefix/origin match exists).
  /* first check the aut-num authorization */
  if ( the referenced aut-num object does not exist or
       the aut-num authorization fails )
    authorization fails
  /* next we check for prefix authorization */
  if ( a less specific route(s) with the longest prefix is found ) [
    if ( authorization does not pass for at least one of the less
         specific route(s) )
      authorization fails
  /* now check for a "reclaim" attr */
    if ( the object has a "reclaim" attribute ) [
      if ( no more-specifics exist
           OR a less specific exists which passes
              authorization and has a "reclaim" attribute

Villamizar, et al. Standards Track [Page 36] RFC 2725 Routing Policy System Security December 1999

           OR all more specifics routess pass modify authorization )
        authorization passes
      else
        authorization fails
    ] else
      authorization passes
  ]
  /* there are no less specific routes to check for prefix
     authentication, so we need to try and get authorization from an
     inetnum object */
  if ( ( an inetnum is found that is an exact match
         OR is less specific and it's status is "allocated" )
       AND a maintainer referenced by the inetnum
           passes authorization )
    authorization succeeds
  /* if there is no inetnum or route object then then
     authorization fails.  This should never happen if
     the DB is initialized properly. */
  authorization fails.
  Case #2.  Route object modify/delete
            (ie, exact prefix/origin match exists).
  if ( the mnt-by passes authorization )
    authorization succeeds
  /* if the authorization did not pass from the matched object,
     we can still get authorization from a less specific route if it
     has a "reclaim" attribute and we pass authorization */
  if ( a less specific route or inetnum object passes authorization
       AND has a "reclaim" attribute applicable to
           the object to be modified )
    authorization succeeds
  else
    authorization fails

Acknowledgments

 This document draws ideas from numerous discussions and contributions
 of the IETF Routing Policy System Work Group and RIPE Routing Work
 Group.  Earlier drafts of this document listed Carol Orange as a co-
 author.  Carol Orange made contributions to this document while at
 RIPE.

Villamizar, et al. Standards Track [Page 37] RFC 2725 Routing Policy System Security December 1999

 Gerald Winters provided the pseudocode in an email message to the
 RIPE dbsec mailing list that was the basis of the pseudocode found in
 appendix F.  Susan Harris provided comments and numerous editorial
 corrections.

Intellectual Property Notice

 The IETF takes no position regarding the validity or scope of any
 intellectual property or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; neither does it represent that it
 has made any effort to identify any such rights.  Information on the
 IETF's procedures with respect to rights in standards-track and
 standards-related documentation can be found in BCP-11.  Copies of
 claims of rights made available for publication and any assurances of
 licenses to be made available, or the result of an attempt made to
 obtain a general license or permission for the use of such
 proprietary rights by implementors or users of this specification can
 be obtained from the IETF Secretariat.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights which may cover technology that may be required to practice
 this standard.  Please address the information to the IETF Executive
 Director.

References

  [1]  Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer,
       D., Terpstra M. and C. Villamizar, "Routing Policy
       Specification Language (RPSL)", RFC 2280, January 1998.
  [2]  Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M.,
       Karrenberg, D., Terpstra, M. and J. Yu, "Representation of IP
       Routing Policies in a Routing Registry (ripe-81++)", RFC 1786,
       March 1995.
  [3]  Berkowitz, H., "Router Renumbering Guide", RFC 2072, January
       1997.
  [4]  Braun, H-W., "Models of policy based routing", RFC 1104, June
       1989.
  [5]  Braun, H-W. and Y. Rekhter, "Advancing the NSFNET routing
       architecture", RFC 1222, May 1991.

Villamizar, et al. Standards Track [Page 38] RFC 2725 Routing Policy System Security December 1999

  [6]  Clark, D., "Policy routing in Internet protocols", RFC 1102,
       May 1989.
  [7]  Crocker, D., "Standard for the format of ARPA Internet text
       messages", STD 11, RFC 822, August 1982.
  [8]  Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-
       Domain Routing (CIDR): an Address Assignment and Aggregation
       Strategy", RFC 1519, September 1993.
  [9]  Internet Engineering Steering Group and R. Hinden,
       "Applicability Statement for the Implementation of Classless
       Inter-Domain Routing (CIDR)", RFC 1517, September 1993.
 [10]  Hawkinson, J. and T. Bates, "Guidelines for creation,
       selection, and registration of an Autonomous System (AS)", RFC
       1930, March 1996.
 [11]  Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J.
       Postel, "Internet Registry IP Allocation Guidelines", BCP 12,
       RFC 2050, November 1996.
 [12]  Knopper, M.  and S. Richardson, "Aggregation Support in the
       NSFNET Policy-Based Routing Database", RFC 1482, June 1993.
 [13]  Meyer, D., Prior, M., Alaettinoglu, C., Schmitz, J. and Carol
       Orange, "Using RPSL in Practice", RFC 2650, August 1999.
 [14]  Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787,
       April 1995.
 [15]  Rekhter Y. and T. Li, "An Architecture for IP Address
       Allocation with CIDR", RFC 1518, September 1993.
 [16]  Rekhter Y. and T. Li, "Implications of Various Address
       Allocation Policies for Internet Routing", RFC 2008, October
       1996.
 [17]  Rekhter, Y., Lothberg, P., Hinden, R., Deering, S. and J.
       Postel, "An IPv6 Provider-Based Unicast Address Format", RFC
       2073, January 1997.
 [18]  Zsako, J., "PGP Authentication for RIPE Database Updates", RFC
       2726, December 1999.

Villamizar, et al. Standards Track [Page 39] RFC 2725 Routing Policy System Security December 1999

Security Considerations

 This document primarily addresses authorization rules for making
 additions, deletions, and changes to routing policy information
 repositories.  The authentication of these transactions through
 strong cryptographic means are addressed by [18], referenced
 thorughout this document.  The authorization rules are designed such
 that the integrity of any transaction can be verified independently
 by any party mirroring a repository to insure that rules are adhered
 to.  To accomplish this the mirror must contain data already known to
 be properly authorized.  In other words, the mirror must be complete
 and authentication and authorization checks must be made continuously
 as changes to the repository are recieved and processed in order.
 Authentication alone does not provide a complete security model.
 Current practice specifies authorization for deletions and changes
 only, not for additions.  The authorization rules provide here
 complete the security model for additions, deletions, and changes by
 very explicitly defining rules for addition and clarifying procedures
 for handling exception cases such as organizations which have ceased
 to exist and therefore become entirely unresponsive.
 Authentication and authorization of queries is explicitly stated to
 be out of scope of this document.

Authors' Addresses

 Curtis Villamizar
 Avici Systems
 EMail: curtis@avici.com
 Cengiz Alaettinoglu
 ISI
 EMail: cengiz@ISI.EDU
 David M. Meyer
 Cisco
 EMail: dmm@cisco.com
 Sandy Murphy
 Trusted Information Systems
 EMail: sandy@tis.com

Villamizar, et al. Standards Track [Page 40] RFC 2725 Routing Policy System Security December 1999

Full Copyright Statement

 Copyright (C) The Internet Society (1999).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Villamizar, et al. Standards Track [Page 41]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2725.txt · Last modified: 1999/12/11 00:55 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki