doc: Add RFC documents

1 files changed, 2355 insertions, 0 deletions

diff --git a/doc/rfc/rfc2769.txt b/doc/rfc/rfc2769.txt
new file mode 100644
index 0000000..7d2398b
--- /dev/null
+++ b/doc/rfc/rfc2769.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group                                      C. Villamizar
+Request for Comments: 2769                                 Avici Systems
+Category: Standards Track                                C. Alaettinoglu
+                                                             R. Govindan
+                                                                     ISI
+                                                                D. Meyer
+                                                                   Cisco
+                                                           February 2000
+
+
+                   Routing Policy System Replication
+
+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 (2000).  All Rights Reserved.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+Abstract
+
+   The RIPE database specifications and RPSL 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 use.  The Routing Policy System Security RFC [3] addresses the
+   need to assure integrity of the data by proposing an authentication
+   and authorization model.  This document addresses the need to
+   distribute data over multiple repositories and delegate authority for
+   data subsets to other repositories without compromising the
+   authorization model established in Routing Policy System Security
+   RFC.
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                     [Page 1]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+Table of Contents
+
+   1  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2  Data Representation  . . . . . . . . . . . . . . . . . . . . .   4
+   3  Authentication and Authorization . . . . . . . . . . . . . . .   5
+   4  Repository Hierarchy . . . . . . . . . . . . . . . . . . . . .   6
+   5  Additions to RPSL  . . . . . . . . . . . . . . . . . . . . . .   6
+      5.1  repository object . . . . . . . . . . . . . . . . . . . .   7
+      5.2  delegated attribute . . . . . . . . . . . . . . . . . . .   9
+      5.3  integrity attribute . . . . . . . . . . . . . . . . . . .  10
+   6  Interactions with a Repository or Mirror . . . . . . . . . . .  11
+      6.1  Initial Transaction Submission  . . . . . . . . . . . . .  12
+      6.2  Redistribution of Transactions  . . . . . . . . . . . . .  12
+      6.3  Transaction Commit and Confirmation . . . . . . . . . . .  12
+   7  Data Format Summaries, Transaction Encapsulation and Processing 13
+      7.1  Transaction Submit and Confirm  . . . . . . . . . . . . .  13
+      7.2  Redistribution of Transactions  . . . . . . . . . . . . .  16
+      7.3  Redistribution Protocol Description . . . . . . . . . . .  16
+           7.3.1 Explicitly Requesting Transactions  . . . . . . . .  21
+           7.3.2 Heartbeat Processing  . . . . . . . . . . . . . . .  22
+      7.4  Transaction Commit  . . . . . . . . . . . . . . . . . . .  23
+      7.5  Database Snapshot . . . . . . . . . . . . . . . . . . . .  24
+      7.6  Authenticating Operations . . . . . . . . . . . . . . . .  25
+   A  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  27
+      A.1  Initial Object Submission and Redistribution  . . . . . .  27
+      A.2  Transaction Redistribution Encoding . . . . . . . . . . .  29
+      A.3  Transaction Protocol Encoding . . . . . . . . . . . . . .  31
+      A.4  Transaction Redistribution  . . . . . . . . . . . . . . .  32
+   B  Technical Discussion . . . . . . . . . . . . . . . . . . . . .  35
+      B.1  Server Processing . . . . . . . . . . . . . . . . . . . .  35
+           B.1.1 getting connected . . . . . . . . . . . . . . . . .  35
+           B.1.2 rolling transaction logs forward and back . . . . .  35
+           B.1.3 committing or disposing of transactions . . . . . .  36
+           B.1.4 dealing with concurrency  . . . . . . . . . . . . .  36
+      B.2  Repository Mirroring for Redundancy . . . . . . . . . . .  36
+      B.3  Trust Relationships . . . . . . . . . . . . . . . . . . .  37
+      B.4  A Router as a Minimal Mirror  . . . . . . . . . . . . . .  38
+      B.5  Dealing with Errors . . . . . . . . . . . . . . . . . . .  38
+   C  Deployment Considerations  . . . . . . . . . . . . . . . . . .  39
+   D  Privacy of Contact Information . . . . . . . . . . . . . . . .  39
+   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  40
+   Security Considerations . . . . . . . . . . . . . . . . . . . . .  41
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41
+   Full Copyright Statement  . . . . . . . . . . . . . . . . . . . .  42
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                     [Page 2]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+1  Overview
+
+   A routing registry must maintain some degree of integrity to be of
+   any use.  The IRR is increasingly used for purposes that have a
+   stronger requirement for data integrity and security.  There is also
+   a desire to further decentralize the IRR. This document proposes a
+   means of decentralizing the routing registry in a way that is
+   consistent with the usage of the IRR and which avoids compromising
+   data integrity and security even if the IRR is distributed among less
+   trusted repositories.
+
+   Two methods of authenticating the routing registry information have
+   been proposed.
+
+   authorization and authentication checks on transactions:  The
+      integrity of the routing registry data is insured by repeating
+      authorization checks as transactions are processed.  As
+      transactions are flooded each remote registry has the option to
+      repeat the authorization and authentication checks.  This scales
+      with the total number of changes to the registry regardless of how
+      many registries exist.  When querying, the integrity of the
+      repository must be such that it can be trusted.  If an
+      organization is unwilling to trust any of the available
+      repositories or mirrors they have the option to run their own
+      mirror and repeat authorization checks at that mirror site.
+      Queries can then be directed to a mirror under their own
+      administration which presumably can be trusted.
+
+   signing routing registry objects:  An alternate which appears on the
+      surface to be attractive is signing the objects themselves.
+      Closer examination reveals that the approach of signing objects by
+      itself is flawed and when used in addition to signing transactions
+      and rechecking authorizations as changes are made adds nothing.
+      In order for an insertion of critical objects such as inetnums and
+      routes to be valid, authorization checks must be made which allow
+      the insertion.  The objects on which those authorization checks
+      are made may later change.  In order to later repeat the
+      authorization checks the state of other objects, possibly in other
+      repositories would have to be known.  If the repository were not
+      trusted then the change history on the object would have to be
+      traced back to the object's insertion.  If the repository were not
+      trusted, the change history of any object that was depended upon
+      for authorization would also have to be rechecked.  This trace
+      back would have to go back to the epoch or at least to a point
+      where only trusted objects were being relied upon for the
+      authorizations.  If the depth of the search is at all limited,
+      authorization could be falsified simply by exceeding the search
+      depth with a chain of authorization references back to falsified
+
+
+
+Villamizar, et al.          Standards Track                     [Page 3]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+      objects.  This would be grossly inefficient.  Simply verifying
+      that an object is signed provides no assurance that addition of
+      the object addition was properly authorized.
+
+   A minor distinction is made between a repository and a mirror.  A
+   repository has responsibility for the initial authorization and
+   authentication checks for transactions related to its local objects
+   which are then flooded to adjacent repositories.  A mirror receives
+   flooded transactions from remote repositories but is not the
+   authoritative source for any objects.  From a protocol standpoint,
+   repositories and mirrors appear identical in the flooding topology.
+
+   Either a repository or a mirror may recheck all or a subset of
+   transactions that are flooded to it.  A repository or mirror may
+   elect not to recheck authorization and authentication on transactions
+   received from a trusted adjacency on the grounds that the adjacent
+   repository is trusted and would not have flooded the information
+   unless authorization and authentication checks had been made.
+
+   If it can be arranged that all adjacencies are trusted for a given
+   mirror, then there is no need to implement the code to check
+   authorization and authentication.  There is only a need to be able to
+   check the signatures on the flooded transactions of the adjacent
+   repository.  This is an important special case because it could allow
+   a router to act as a mirror.  Only changes to the registry database
+   would be received through flooding, which is a very low volume.  Only
+   the signature of the adjacent mirror or repository would have to be
+   checked.
+
+2  Data Representation
+
+   RPSL provides a complete description of the contents of a routing
+   repository [1].  Many RPSL data objects remain unchanged from the
+   RIPE, 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.  The integrity
+   of the distributed registry data requires the use of the
+   authorization and authentication additions to RPSL described in [3].
+
+   Some additions to RPSL are needed to locate all of the repositories
+   after having located one of them and to make certain parameters
+   selectable on a per repository basis readily available.  These
+   additions are described in Section 5.
+
+   Some form of encapsulation must be used to exchange data.  The de-
+   facto encapsulation has been that 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
+
+
+
+Villamizar, et al.          Standards Track                     [Page 4]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   the mail headers.  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.
+
+   The exchange that occurs during flooding differs from the initial
+   submission.  In order to repeat the authorization checks the state of
+   all repositories containing objects referenced by the authorization
+   checks needs to be known.  To accomplish this a sequence number is
+   associated with each transaction in a repository and the flooded
+   transactions must contain the sequence number of each repository on
+   which authorization of the transaction depends.
+
+   In order to repeat authorization checks it must be possible to
+   retrieve back revisions of objects.  How this is accomplished is a
+   matter local to the implementation.  One method which is quite simple
+   is to keep the traversal data structures to all current objects even
+   if the state is deleted, keep the sequence number that the version of
+   the object became effective and keep back links to prior versions of
+   the objects.  Finding a prior version of an object involves looking
+   back through the references until the sequence number of the version
+   of the object is less than or equal to the sequence number being
+   searched for.
+
+   The existing very simple forms of encapsulation are adequate for the
+   initial submission of a database transaction and should be retained
+   as long as needed for backward compatibility.  A more robust
+   encapsulation and submission protocol, with optional confirmation is
+   defined in Section 6.1.  An encapsulation suitable for exchange of
+   transaction between repositories is addressed in Section 6.  Query
+   encapsulation and protocol is outside the scope of this document.
+
+3  Authentication and Authorization
+
+   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.
+
+   A submitted transaction contains a claimed identity.  Depending on
+   the type of transaction, the authorization will depend on related
+   objects.
+
+
+
+
+Villamizar, et al.          Standards Track                     [Page 5]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   The "mnt-by", "mnt-routes", or "mnt-lower" attributes in those
+   related objects reference "maintainer" objects.  Those maintainer
+   objects contain "auth" attributes.  The auth attributes contain an
+   authorization method and data which generally contains the claimed
+   identity and some form of public encryption key used to authenticate
+   the claim.
+
+   Authentication is done on transactions.  Authentication should also
+   be done between repositories to insure the integrity of the
+   information exchange.  In order to comply with import, export, and
+   use restrictions throughout the world no encryption capability is
+   specified.  Transactions must not be encrypted because it may be
+   illegal to use decryption software in some parts of the world.
+
+4  Repository Hierarchy
+
+   With multiple repositories, "repository" objects are needed to
+   propagate the existence of new repositories and provide an automated
+   means to determine the supported methods of access and other
+   characteristics of the repository.  The repository object is
+   described in Section 5.
+
+   In each repository there should be a special repository object named
+   ROOT. This should point to the root repository or to a higher level
+   repository.  This is to allow queries to be directed to the local
+   repository but refer to the full set of registries for resolution of
+   hierarchically allocated objects.
+
+   Each repository may have an "expire" attribute.  The expire attribute
+   is used to determine if a repository must be updated before a local
+   transaction that depends on it can proceed.
+
+   The repository object also contains attributes describing the access
+   methods and supported authentication methods of the repository.  The
+   "query-address" attribute provides a host name and a port number used
+   to direct queries.  The "response-auth-type" attribute provides the
+   authentication types that may be used by the repository when
+   responding to queries.  The "submit-address" attribute provides a
+   host name and a port number used to submit objects to the repository.
+   The "submit-auth-type" attribute provides the authentication types
+   that may be used by the repository when responding to submissions.
+
+5  Additions to RPSL
+
+   There are very few additions to RPSL defined here.  The additions to
+   RPSL are referred to as RPSL "objects".  They reside in the
+   repository database and can be retrieved with ordinary queries.
+   Objects consist of "attributes", which are name/value pairs.
+
+
+
+Villamizar, et al.          Standards Track                     [Page 6]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   Attributes may be mandatory or optional.  They may be single or
+   multiple.  One or more attributes may be part of a key field.  Some
+   attributes may have the requirement of being unique.
+
+   Most of the data formats described in this document are
+   encapsulations used in transaction exchanges.  These are referred to
+   as "meta-objects".  These "meta-objects", unlike RPSL "objects" do
+   not reside in the database but some must be retained in a transaction
+   log.  A similar format is used to represent "meta-objects".  They
+   also consist of "attributes" which are name/value pairs.
+
+   This section contains all of the additions to RPSL described in this
+   document.  This section describes only RPSL objects.  Other sections
+   described only meta-objects.
+
+5.1  repository object
+
+   A root repository must be agreed upon.  Ideally such a repository
+   would contain only top level delegations and pointers to other
+   repositories used in these delegations.  It would be wise to allow
+   only cryptographically strong transactions in the root repository
+   [3].
+
+   The root repository contains references to other repositories.  An
+   object of the following form identifies another repository.
+
+     repository:         RIPE
+     query-address:      whois://whois.ripe.net
+     response-auth-type: PGPKEY-23F5CE35 # pointer to key-cert object
+     response-auth-type: none
+     remarks:            you can request rsa signature on queries
+     remarks:            PGP required on submissions
+     submit-address:     mailto://auto-dbm@ripe.net
+     submit-address:     rps-query://whois.ripe.net:43
+     submit-auth-type:   pgp-key, crypt-pw, mail-from
+     remarks:            these are the authentication types supported
+     mnt-by:             maint-ripe-db
+     expire:             0000 04:00:00
+     heartbeat-interval: 0000 01:00:00
+     ...
+     remarks:            admin and technical contact, etc
+     source:             IANA
+
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                     [Page 7]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   The attributes of the repository object are listed below.
+
+     repository      key  mandatory  single
+     query-address        mandatory  multiple
+     response-auth-type   mandatory  multiple
+     submit-address       mandatory  multiple
+     submit-auth-type     mandatory  multiple
+     repository-cert      mandatory  multiple
+     expire               mandatory  single
+     heartbeat-interval   mandatory  single
+     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
+
+   In the above object type only a small number of the attribute types
+   are new.  These are:
+
+   repository  This attribute provides the name of the repository.  This
+      is the key field for the object and is single and must be globally
+      unique.  This is the same name used in the source attribute of all
+      objects in that repository.
+
+   query-address  This attribute provides a url for directing queries.
+      "rps-query" or "whois" can be used as the protocol identifier.
+
+   response-auth-type  This attribute provides an authentication type
+      that may be used by the repository when responding to user
+      queries.  Its syntax and semantics is same as the auth attribute
+      of the maintainer class.
+
+   submit-address  This attribute provides a url for submitting objects
+      to the repository.
+
+   submit-auth-type  This attribute provides the authentication types
+      that are allowed by the repository for users when submitting
+      registrations.
+
+   repository-cert  This attribute provides a reference to a public key
+      certificate in the form of an RPSL key-cert object.  This
+      attribute can be multiple to allow the repository to use more than
+      one method of signature.
+
+
+
+
+
+Villamizar, et al.          Standards Track                     [Page 8]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   heartbeat-interval  Heartbeat meta-objects are sent by this
+      repository at the rate of one heartbeat meta-object per the
+      interval indicated.  The value of this attribute shall be
+      expressed in the form "dddd hh:mm:ss", where the "dddd" represents
+      days, "hh" represents hours, "mm" minutes and "ss" seconds.
+
+   expire  If no heartbeat or new registrations are received from a
+      repository for expire period, objects from this repository should
+      be considered non-authoritative, and cannot be used for
+      authorization purposes.  The value of this attribute shall be
+      expressed in the form "dddd hh:mm:ss", where the "dddd" represents
+      days, "hh" represents hours, "mm" minutes and "ss" seconds.  This
+      value should be bigger than heartbeat-interval.
+
+   Please note that the "heartbeat" meta-objects mentioned above, like
+   other meta-objects described in this document are part of the
+   protocol to exchange information but are not placed in the database
+   itself.  See Section 7.3.2 for a description of the heartbeat meta-
+   object.
+
+   The remaining attributes in the repository object are defined in
+   RPSL.
+
+5.2  delegated attribute
+
+   For many RPSL object types a particular entry should appear only in
+   one repository.  These are the object types for which there is a
+   natural hierarchy, "as-block", "aut-num", "inetnum", and "route".  In
+   order to facilitate putting an object in another repository, a
+   "delegated" attribute is added.
+
+   delegated  The delegated attribute is allowed in any object type with
+      a hierarchy.  This attribute indicates that further searches for
+      object in the hierarchy must be made in one or more alternate
+      repositories.  The current repository may be listed.  The ability
+      to list more than one repository serves only to accommodate
+      grandfathered objects (those created prior to using an
+      authorization model).  The value of a delegated attribute is a
+      list of repository names.
+
+   If an object contains a "delegated" attribute, an exact key field
+   match of the object may also be contained in each repository listed
+   in the "delegated" attribute.  For the purpose of authorizing changes
+   only the "mnt-by" in the object in the repository being modified is
+   considered.
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                     [Page 9]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   The following is an example of the use of a "delegated" attribute.
+
+     inetnum:        193.0.0.0 - 193.0.0.255
+     delegated:      RIPE
+     ...
+     source:         IANA
+
+   This inetnum simply delegates the storage of any more specific
+   inetnum objects overlapping the stated range to the RIPE repository.
+   An exact match of this inetnum may also exist in the RIPE repository
+   to provide hooks for the attributes referencing maintainer objects.
+   In this case, when adding objects to the RIPE repository, the "mnt-
+   lower", "mnt-routes", and "mnt-by" fields in the IANA inetnum object
+   will not be considered, instead the values in the RIPE copy will be
+   used.
+
+5.3  integrity attribute
+
+   The "integrity" attribute can be contained in any RPSL object.  It is
+   intended solely as a means to facilitate a transition period during
+   which some data has been moved from repositories prior to the use of
+   a strong authorization model and is therefore questionable, or when
+   some repositories are not properly checking authorization.
+
+   The "integrity" attribute may have the values "legacy", "no-auth",
+   "auth-failed", or "authorized".  If absent, the integrity is
+   considered to be "authorized".  The integrity values have the
+   following meanings:
+
+   legacy:  This data existed prior to the use of an adequate
+      authorization model.  The data is highly suspect.
+
+   no-auth:  This data was added to a repository during an initial
+      transition use of an authorization model but authorization
+      depended on other objects whose integrity was not "authorized".
+      Such an addition is being allowed during the transition but would
+      be disallowed later.
+
+   auth-failed:  The authoritative repository is not checking
+      authorization.  Had it been doing so, authorization would have
+      failed.  This attribute may be added by a repository that is
+      mirroring before placing the object in its local storage, or can
+      add this attribute to an encapsulating meta-object used to further
+      propagate the transaction.  If the failure to enforce
+      authorization is intentional and part of a transition (for
+      example, issuing warnings only), then the authoritative repository
+      may add this attribute to the encapsulating meta-object used to
+      further propagate the transaction.
+
+
+
+Villamizar, et al.          Standards Track                    [Page 10]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   authorized:  Authorization checks were passed.  The maintainer
+      contained a "referral-by" attribute, a form of authentication
+      deemed adequate by the repository was used, and all objects that
+      were needed for authorization were objects whose integrity was
+      "authorized".
+
+   Normally once an object is added to a repository another object
+   cannot overwrite it unless authorized to do so by the maintainers
+   referenced by the "mnt-by" attributes in the object itself.  If the
+   integrity attribute is anything but "authorized", an object can be
+   overwritten or deleted by any transaction that would have been a
+   properly authorized addition had the object of lesser integrity not
+   existed.
+
+   During such a transition grandfathered data and data added without
+   proper authorization becomes advisory until a properly authorized
+   addition occurs.  After transition additions of this type would no
+   longer be accepted.  Those objects already added without proper
+   authorization would remain but would be marked as candidates for
+   replacement.
+
+6  Interactions with a Repository or Mirror
+
+   This section presents an overview of the transaction distribution
+   mechanisms.  The detailed format of the meta-objects for
+   encapsulating and distributing transactions, and the rules for
+   processing meta-objects are described in Section 7.  There are a few
+   different types of interactions between routing repositories or
+   mirrors.
+
+   Initial submission of transactions:  Transactions may include
+      additions, changes, and deletions.  A transaction may operate on
+      more than one object and must be treated as an atomic operation.
+      By definition initial submission of transactions is not applicable
+      to a mirror.  Initial submission of transactions is described in
+      Section 6.1.
+
+   Redistribution of Transactions:  The primary purpose of the
+      interactions between registries is the redistribution of
+      transactions.  There are a number of ways to redistribute
+      transactions.  This is discussed in Section 6.2.
+
+   Queries:  Query interactions are outside the scope of this document.
+
+   Transaction Commit and Confirmation:  Repositories may optionally
+      implement a commit protocol and a completion indication that gives
+      the submitter of a transaction a response that indicates that a
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 11]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+      transaction has been successful and will not be lost by a crash of
+      the local repository.  A submitter may optionally request such a
+      confirmation.  This is discussed in Section 6.3.
+
+6.1  Initial Transaction Submission
+
+   The simplest form of transaction submission is an object or set of
+   objects submitted with RFC-822 email encapsulation.  This form is
+   still supported for backwards compatibility.  A preferred form allows
+   some meta-information to be included in the submission, such as a
+   preferred form of confirmation.  Where either encapsulation is used,
+   the submitter will connect to a host and port specified in the
+   repository object.  This allows immediate confirmation.  If an email
+   interface similar to the interface provided by the existing RIPE code
+   is desired, then an external program can provide the email interface.
+
+   The encapsulation of a transaction submission and response is
+   described in detail in Section 7.
+
+
+6.2  Redistribution of Transactions
+
+   Redistribution of transactions can be accomplished using one of:
+
+   1. A repository snapshot is a request for the complete contents of a
+      given repository.  This is usually done when starting up a new
+      repository or mirror or when recovering from a disaster, such as a
+      disk crash.
+
+   2. A transaction sequence exchange is a request for a specific set of
+      transactions.  Often the request is for the most recent sequence
+      number known to a mirror to the last transactions.  This is used
+      in polling.
+
+   3. Transaction flooding is accomplished through a unicast adjacency.
+
+   This section describes the operations somewhat qualitatively.  Data
+   formats and state diagrams are provided in Section 7.
+
+6.3  Transaction Commit and Confirmation
+
+   If a submission requires a strong confirmation of completion, or if a
+   higher degree of protection against false positive confirmation is
+   desired as a matter of repository policy, a commit may be performed.
+
+   A commit request is a request from the repository processing an
+   initial transaction submission to another repository to confirm that
+   they have been able to advance the transaction sequence up to the
+
+
+
+Villamizar, et al.          Standards Track                    [Page 12]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   sequence number immediately below the transaction in the request and
+   are willing to accept the transaction in the request as a further
+   advance in the sequence.  This indicates that either the
+   authorization was rechecked by the responding repository and passed
+   or that the responding repository trusts the requesting repository
+   and has accepted the transaction.
+
+   A commit request can be sent to more than one alternate repository.
+   One commit completion response is sufficient to respond to the
+   submitter with a positive confirmation that the transaction has been
+   completed.  However, the repository or submitter may optionally
+   require more than one.
+
+7  Data Format Summaries, Transaction Encapsulation and Processing
+
+   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 consecutive whitespace characters is equivalent to a
+   single space.  Line continuation is supported by putting a white
+   space or '+' character to the beginning of the continuation lines.
+   An object is externally represented as a sequence of attributes.
+   Objects are separated by blank lines.
+
+   Protocol interactions between registries are activated by passing
+   "meta objects".  Meta objects are not part of RPSL but conform to
+   RPSL object representation.  They serve mostly as delimiters to the
+   protocol messages or to carry the request for an operation.
+
+7.1  Transaction Submit and Confirm
+
+   The de-facto method for submitting database changes has been via
+   email.  This method should be supported by an external application.
+   Merit has added the pgp-from authentication method to the RADB
+   (replaced by "pgpkey" in [4]), where the mail headers are essentially
+   ignored and the body of the mail message must be PGP signed.
+
+   This specification defines a different encapsulation for transaction
+   submission.  When submitting a group of objects to a repository, a
+   user MUST append to that group of objects, exactly one "timestamp"
+   and one or more "signature" meta-objects, in that order.
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 13]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   The "timestamp" meta-object contains a single attribute:
+
+   timestamp  This attribute is mandatory and single-valued.  This
+      attribute specifies the time at which the user submits the
+      transaction to the repository.  The format of this attribute is
+      "YYYYMMDD hh:mm:ss [+/-]xx:yy", where "YYYY" specifies the four
+      digit year, "MM" represents the month, "DD" the date, "hh" the
+      hour, "mm" the minutes, "ss" the seconds of the timestamp, and
+      "xx" and "yy" represents the hours and minutes respectively that
+      that timestamp is ahead or behind UTC.
+
+   A repository may reject a transaction which does not include the
+   "timestamp" meta-object.  The timestamp object is used to prevent
+   replaying registrations.  How this is actually used is a local
+   matter.  For example, a repository can accept a transaction only if
+   the value of the timestamp attribute is greater than the timestamp
+   attribute in the previous registration received from this user
+   (maintainer), or the repository may only accept transactions with
+   timestamps within its expire window.
+
+   Each "signature" meta-object contains a single attribute:
+
+   signature  This attribute is mandatory and single-valued.  This
+      attribute, a block of free text, contains the signature
+      corresponding to the authentication method used for the
+      transaction.  When the authentication method is a cryptographic
+      hash (as in PGP-based authentication), the signature must include
+      all text up to (but not including) the last blank line before the
+      first "signature" meta-object.
+
+   A repository must reject a transaction that does not include any
+   "signature" meta-object.
+
+   The group of objects submitted by the user, together with the
+   "timestamp" and "signature" meta-objects, constitute the "submitted
+   text" of the transaction.
+
+   The protocol used for submitting a transaction, and for receiving
+   confirmation of locally committed transactions, is not specified in
+   this document.  This protocol may define additional encapsulations
+   around the submitted text.  The rest of this section gives an example
+   of one such protocol.  Implementations are free to choose another
+   encapsulation.
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 14]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   The meta-objects "transaction-submit-begin" and "transaction-submit-
+   end" delimit a transaction.  A transaction is handled as an atomic
+   operation.  If any part of the transaction fails none of the changes
+   take effect.  For this reason a transaction can only operate on a
+   single database.
+
+   A socket connection is used to request queries or submit
+   transactions.  An email interface may be provided by an external
+   program that connects to the socket.  A socket connection must use
+   the "transaction-submit-begin" and "transaction-submit-end"
+   delimiters but can request a legacy style confirmation.  Multiple
+   transactions may be sent prior to the response for any single
+   transaction.  Transactions may not complete in the order sent.
+
+   The "transaction-submit-begin" meta-object may contain the following
+   attributes.
+
+   transaction-submit-begin  This attribute is mandatory and single.
+      The value of the attribute contains name of the database and an
+      identifier that must be unique over the course of the socket
+      connection.
+
+   response-auth-type  This attribute is optional and multiple.  The
+      remainder of the line specifies an authentication type that would
+      be acceptable in the response.  This is used to request a response
+      cryptographically signed by the repository.
+
+   transaction-confirm-type  This attribute is optional and single.  A
+      confirmation type keyword must be provided.  Keywords are "none",
+      "legacy", "normal", "commit".  The confirmation type can be
+      followed by the option "verbose".
+
+   The "transaction-submit-end meta-object consists of a single
+   attribute by the same name.  It must contain the same database name
+   and identifier as the corresponding "transaction-submit-begin"
+   attribute.
+
+   Unless the confirmation type is "none" a confirmation is sent.  If
+   the confirmation type is "legacy", then an email message of the form
+   currently sent by the RIPE database code will be returned on the
+   socket (suitable for submission to the sendmail program).
+
+   A "normal" confirmation does not require completion of the commit
+   protocol.  A "commit" confirmation does.  A "verbose" confirmation
+   may contain additional detail.
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 15]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   A transaction confirmation is returned as a "transaction-confirm"
+   meta-object.  The "transaction-confirm" meta-object may have the
+   following attributes.
+
+   transaction-confirm  This attribute is mandatory and single.  It
+      contains the database name and identifier associated with the
+      transaction.
+
+   confirmed-operation  This attribute is optional and multiple.  It
+      contains one of the keywords "add", "delete" or "modify" followed
+      by the object type and key fields of the object operated on.
+
+   commit-status  This attribute is mandatory and single.  It contains
+      one of the keywords "succeeded, "error", or "held".  The "error"
+      keyword may be followed by an optional text string.  The "held"
+      keyword is returned when a repository containing a dependent
+      object for authorization has expired.
+
+7.2  Redistribution of Transactions
+
+   In order to redistribute transactions, each repository maintains a
+   TCP connection with one or more other repositories.  After locally
+   committing a submitted transaction, a repository assigns a sequence
+   number to the transaction, signs and encapsulates the transaction,
+   and then sends one copy to each neighboring (or "peer") repository.
+   In turn, each repository authenticates the transaction (as described
+   in Section 7.6), may re-sign the transaction and redistributes the
+   transaction to its neighbors.  We use the term "originating
+   repository" to distinguish the repository that redistributes a
+   locally submitted transaction.
+
+   This document also specifies two other methods for redistributing
+   transactions to other repositories:  a database snapshot format used
+   for initializing a new registry, and a polling technique used by
+   mirrors.
+
+   In this section, we first describe how a repository may encapsulate
+   the submitted text of a transaction.  We then describe the protocol
+   for flooding transactions or polling for transactions, and the
+   database snapshot contents and format.
+
+7.3  Redistribution Protocol Description
+
+   The originating repository must first authenticate a submitted
+   transaction using methods described in [3].
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 16]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   Before redistributing a transaction, the originating repository must
+   encapsulate the submitted text of the transaction with several meta-
+   objects, which are described below.
+
+   The originating repository must prepend the submitted text with
+   exactly one "transaction-label" meta-object.  This meta-object
+   contains the following attributes:
+
+   transaction-label  This attribute is mandatory and single.  The value
+      of this attribute conforms to the syntax of an RPSL word, and
+      represents a globally unique identifier for the database to which
+      this transaction is added.
+
+   sequence  This attribute is mandatory and single.  The value of this
+      attribute is an RPSL integer specifying the sequence number
+      assigned by the originating repository to the transaction.
+      Successive transactions distributed by the same originating
+      repository have successive sequence numbers.  The first
+      transaction originated by a registry is assigned a sequence number
+      1.  Each repository must use sequence numbers drawn from a range
+      at least as large as 64 bit unsigned integers.
+
+   timestamp  This attribute is mandatory and single-valued.  This
+      attribute specifies the time at which the originating repository
+      encapsulates the submitted text.  The format of this attribute is
+      "YYYYMMDD hh:mm:ss [+/-]xx:yy", where "YYYY" specifies the four
+      digit year, "MM" represents the month, "DD" the date, "hh" the
+      hour, "mm" the minutes, "ss" the seconds of the timestamp, and
+      "xx" and "yy" represents the hours and minutes respectively that
+      that timestamp is ahead or behind UTC.
+
+   integrity  This attribute is optional and single-valued.  It may have
+      the values "legacy", "no-auth", "auth-failed", or "authorized".
+      If absent, the integrity is considered to be "authorized".
+
+   The originating repository may append to the submitted text one or
+   more "auth-dependency" meta-objects.  These meta-objects are used to
+   indicate which other repositories' objects were used by the
+   originating registry to authenticate the submitted text.  The "auth-
+   dependency" meta-objects should be ordered from the most preferred
+   repository to the least preferred repository.  This order is used by
+   a remote repository to tie break between the multiple registrations
+   of an object with the same level of integrity.  The "auth-dependency"
+   meta-object contains the following attributes:
+
+   auth-dependency  This attribute mandatory and single-valued.  It
+      equals a repository name from which an object is used to
+      authorize/authenticate this transaction.
+
+
+
+Villamizar, et al.          Standards Track                    [Page 17]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   sequence  This attribute mandatory and single-valued.  It equals the
+      transaction sequence number of the dependent repository known at
+      the originating repository at the time of processing this
+      transaction.
+
+   timestamp  This attribute mandatory and single-valued.  It equals the
+      timestamp of the dependent repository known at the originating
+      repository at the time of processing this transaction.
+
+   If the originating repository needs to modify submitted objects in a
+   way that the remote repositories can not re-create, it can append an
+   "override-objects" meta-object followed by the modified versions of
+   these objects.  An example modification can be auto assignment of NIC
+   handles.  The "override-objects" meta-object contains the following
+   attributes:
+
+   override-objects  A free text remark.
+
+   Other repositories may or may not honor override requests, or limit
+   the kinds of overrides they allow.
+
+   Following this, the originating repository must append exactly one
+   "repository-signature" meta-object.  The "repository-signature"
+   meta-object contains the following attributes:
+
+   repository-signature  This attribute is mandatory and single-valued.
+      It contains the name of the repository.
+
+   integrity  This attribute is optional and single-valued.  It may have
+      the values "legacy", "no-auth", "auth-failed", or "authorized".
+      If absent, the value is same as the value in the transaction-
+      label.  If a different value is used, the value here takes
+      precedence.
+
+   signature  This attribute is optional and single-valued.  This
+      attribute, a block of free text, contains the repository's
+      signature using the key in the repository-cert attribute of the
+      repository object.  When the authentication method is a
+      cryptographic hash (as in PGP-based authentication), the signature
+      must include all text upto (but not including) this attribute.
+      That is, the "repository-signature" and "integrity" attributes of
+      this object are included.  This attribute is optional since
+      cryptographic authentication may not be available everywhere.
+      However, its use where it is available is highly recommended.
+
+   A repository must reject a redistributed transaction that does not
+   include any "repository-signature" meta-object.
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 18]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   The transaction-label, the submitted text, the dependency objects,
+   the override-objects, the overridden objects, and the repository's
+   signature together constitute what we call the "redistributed text".
+
+   In preparation for redistributing the transaction to other
+   repositories, the originating repository must perform the following
+   protocol encapsulation.  This protocol encapsulation may involve
+   transforming the redistributed text according to one of the
+   "transfer-method"s described below.
+
+   The transformed redistributed text is first prepended with exactly
+   one "transaction-begin" meta-object.  One newline character separates
+   this meta-object from the redistributed text.  This meta-object has
+   the following attributes:
+
+   transaction-begin  This attribute is mandatory and single.  The value
+      of this attribute is the length, in bytes, of the transformed
+      redistributed text.
+
+   transfer-method  This attribute is optional and single-valued.  Its
+      value is either "gzip", or "plain".  The value of the attribute
+      describes the kind of text encoding that the repository has
+      performed on the redistributed text.  If this attribute is not
+      specified, its value is assumed to be "plain".  An implementation
+      must be capable of encoding and decoding both of these types.
+
+   The "transaction-begin" meta-object and the transformed redistributed
+   text constitute what we call the "transmitted text".  The originating
+   repository may distribute the transmitted text to one or more peer
+   repositories.
+
+   When a repository receives the transmitted text of a transaction, it
+   must perform the following steps.  After performing the following
+   steps, a transaction may be marked successful or failed.
+
+   1. It must decapsulate the "transaction-begin" meta-object, then
+      decode the original redistributed text according to the value of
+      the transfer-method attribute specified in the "transaction-begin"
+      meta-object.
+
+   2. It should then extract the "transaction-label" meta-object from
+      the transmitted text.  If this transaction has already been
+      processed, or is currently being held, the repository must
+      silently discard this incarnation of the same transaction.
+
+   3. It should verify that the signature of the originating repository
+      matches the first "repository-signature" meta-object in the
+      redistributed text following the "auth-dependency" meta-objects.
+
+
+
+Villamizar, et al.          Standards Track                    [Page 19]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   4. If not all previous (i.e., those with a lower sequence number)
+      transactions from the same repository have been received or
+      completely processed, the repository must "hold" this transaction.
+
+   5. It may check whether any subsequent "repository-signature" meta-
+      objects were appended by a trusted repository.  If so, this
+      indicates that the trusted repository verified the transaction's
+      integrity and marked its conclusion in the integrity attribute of
+      this object.  The repository may verify the trusted repositories
+      signature and also mark the transaction with the same integrity,
+      and skip the remaining steps.
+
+   6. It should verify the syntactic correctness of the transaction.  An
+      implementation may allow configurable levels of syntactic
+      conformance with RPSL [1].  This enables RPSL extensions to be
+      incrementally deployed in the distributed registry scheme.
+
+   7. The repository must authorize and authenticate this transaction.
+      To do this, it may need to reference objects and transactions from
+      other repositories.  If these objects are not available, the
+      repository must "hold" this transaction as described in Section
+      7.6, until it can be authorized and authenticated later.  In order
+      to verify authorization/authentication of this transaction, the
+      repository must not use an object from a repository not mentioned
+      in an "auth-dependency" meta-object.  The repository should also
+      only use the latest objects (by rolling back to earlier versions
+      if necessary) which are within the transaction sequence numbers of
+      the "auth-dependency" meta-objects.
+
+   A non-originating repository must redistribute a failed transaction
+   in order not to cause a gap in the sequence.  (If the transaction was
+   to fail at the originating registry, it would simply not be assigned
+   a sequence number).
+
+   To the redistributed text of a transaction, a repository may append
+   another "repository-signature" meta-object.  This indicates that the
+   repository has verified the transaction's integrity and marked it in
+   the "integrity" attribute of this object.  The signature covers the
+   new redistributed text from (and including) the transaction-label
+   object to this object's signature attribute (including the
+   "repository-signature" and "integrity" attributes of this object, but
+   excluding the "signature" attribute).  The original redistributed
+   text, together with the new "repository-signature" meta-object
+   constitutes the modified redistributed text.
+
+   To redistribute a successful or failed transaction, the repository
+   must encapsulate the (original or modified) redistributed text with a
+   "transaction-begin" object.  This step is essentially the same as
+
+
+
+Villamizar, et al.          Standards Track                    [Page 20]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   that performed by the originating repository (except that the
+   repository is free to use a different "transfer-method" from the one
+   that was in the received transaction.
+
+7.3.1  Explicitly Requesting Transactions
+
+   A repository may also explicitly request one or more transactions
+   belonging to a specified originating repository.  This is useful for
+   catching up after a repository has been off-line for a period of
+   time.  It is also useful for mirrors which intermittently poll a
+   repository for recently received transactions.
+
+   To request a range of transactions from a peer, a repository must
+   send a "transaction-request" meta-object to the peer.  A
+   "transaction-request" meta-object may contain the following
+   attributes:
+
+   transaction-request  This attribute is mandatory and single.  It
+      contains the name of the database whose transactions are being
+      requested.
+
+   sequence-begin  This attribute is optional and single.  It contains
+      the sequence number of the first transaction being requested.
+
+   sequence-end  This attribute is optional and single.  It contains the
+      sequence number of the last transaction being requested.
+
+   Upon receiving a "transaction-request" object, a repository performs
+   the following actions.  If the "sequence-begin" attribute is not
+   specified, the repository assumes the request first sequence number
+   to be 1.  The last sequence number is the lesser of the value of the
+   "sequence-end" attributed and the highest completed transaction in
+   the corresponding database.  The repository then, in order, transmits
+   the requested range of transactions.  Each transaction is prepared
+   exactly according to the rules for redistribution specified in
+   Section 7.3.
+
+   After transmitting all the transactions, the peer repository must
+   send a "transaction-response" meta-object.  This meta-object has the
+   following attributes:
+
+   transaction-response  This attribute is mandatory and single.  It
+      contains the name of the database whose transactions are were
+      requested.
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 21]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   sequence-begin  This attribute is optional and mandatory.  It
+      contains the value of the "sequence-begin" attribute in the
+      original request.  It is omitted if the corresponding attribute
+      was not specified in the original request.
+
+   sequence-end  This attribute is optional and mandatory.  It contains
+      the value of the "sequence-end" attribute in the original request.
+      It is omitted if the corresponding attribute was not specified in
+      the original request.
+
+   After receiving a "transaction-response" meta-object, a repository
+   may tear down the TCP connection to its peer.  This is useful for
+   mirrors that intermittently resynchronize transactions with a
+   repository.  If the TCP connection stays open, repositories exchange
+   subsequent transactions according to the redistribution mechanism
+   specified in Section  7.3.  While a repository is responding to a
+   transaction-request, it MAY forward heartbeats and other transactions
+   from the requested repository towards the requestor.
+
+7.3.2  Heartbeat Processing
+
+   Each repository that has originated at least one transaction must
+   periodically send a "heartbeat" meta-object.  The interval between
+   two successive transmissions of this meta-object is configurable but
+   must be less than 1 day.  This meta-object serves to indicate the
+   liveness of a particular repository.  The repository liveness
+   determines how long transactions are held (See Section 7.6).
+
+   The "heartbeat" meta-object contains the following attributes:
+
+   heartbeat  This attribute is mandatory and single.  It contains the
+      name of the repository which originates this meta-object.
+
+   sequence  This attribute is mandatory and single.  It contains the
+      highest transaction sequence number that has been assigned by the
+      repository.
+
+   timestamp  This attribute is mandatory and single.  It contains the
+      time at which this meta-object was generated.  The format of this
+      attribute is "YYYYMMDD hh:mm:ss [+/-]xx:yy", where "YYYY"
+      specifies the four digit year, "MM" represents the month, "DD" the
+      date, "hh" the hour, "mm" the minutes, "ss" the seconds of the
+      timestamp, and "xx" and "yy" represents the hours and minutes
+      respectively that that timestamp is ahead or behind UTC.
+
+   Upon receiving a heartbeat meta-object, a repository must first check
+   the timestamp of the latest previously received heartbeat message.
+   If that timestamp exceeds the timestamp in the received heartbeat
+
+
+
+Villamizar, et al.          Standards Track                    [Page 22]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   message, the repository must silently discard the heartbeat message.
+   Otherwise, it must record the timestamp and sequence number in the
+   heartbeat message, and redistribute the heartbeat message, without
+   modification, to each of its peer repositories.
+
+   If the heartbeat message is from a repository previously unknown to
+   the recipient, the recipient may send a "transaction-request" to one
+   or more of its peers to obtain all transactions belonging to the
+   corresponding database.  If the heartbeat message contains a sequence
+   number higher than the highest sequence number processed by the
+   recipient, the recipient may send a "transaction-request" to one or
+   more of its peers to obtain all transactions belonging to the
+   corresponding database.
+
+7.4  Transaction Commit
+
+   Submitters may require stronger confirmation of commit for their
+   transactions (Section 6.3).  This section describes a simple
+   request-response protocol by which a repository may provide this
+   stronger confirmation, by verifying if one or more other repositories
+   have committed the transaction.  Implementation of this request-
+   response protocol is optional.
+
+   After it has redistributed a transaction, the originating repository
+   may request a commit confirmation from one or more peer repositories
+   by sending to them a "commit-request" meta-object.  The "commit-
+   request" contains two attributes:
+
+   commit-request  This attribute is mandatory and single.  It contains
+      the name of the database for whom a commit confirmation is being
+      requested.
+
+   sequence  This attribute is mandatory and single.  It contains the
+      transaction sequence number for which a commit confirmation is
+      being requested.
+
+   A repository that receives a "commit-request" must not redistribute
+   the request.  It must delay the response until the corresponding
+   transaction has been processed.  For this reason, the repository must
+   keep state about pending commit requests.  It should discard this
+   state if the connection to the requester is lost before the response
+   is sent.  In that event, it is the responsibility of the requester to
+   resend the request.
+
+   Once a transaction has been processed (Section 7.3), a repository
+   must check to see if there exists any pending commit request for the
+   transaction.  If so, it must send a "commit-response" meta-object to
+   the requester.  This meta-object has three attributes:
+
+
+
+Villamizar, et al.          Standards Track                    [Page 23]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   commit-response  This attribute is mandatory and single.  It contains
+      the name of the database for whom a commit response is being sent.
+
+   sequence  This attribute is mandatory and single.  It contains the
+      transaction sequence number for which a commit response is being
+      sent.
+
+   commit-status  This attribute is mandatory and single.  It contains
+      one of the keywords "held", "error", or "succeeded".  The "error"
+      keyword may be followed by an optional text string.  The "held"
+      keyword is returned when a repository containing a dependent
+      object for authorization has expired.
+
+7.5  Database Snapshot
+
+   A database snapshot provides a complete copy of a database.  It is
+   intended only for repository initialization or disaster recovery.  A
+   database snapshot is an out of band mechanism.  A set of files are
+   created periodically at the source repository.  These files are then
+   transferred to the requestor out of band (e.g.  ftp transfer).  The
+   objects in these files are then registered locally.
+
+   A snapshot of repository X contains the following set of files:
+
+   X.db  This file contains the RPSL objects of repository X, separated
+      by blank lines.  In addition to the RPSL objects and blank lines,
+      comment lines can be present.  Comment lines start with the
+      character '#'.  The comment lines are ignored.  The file X.db ends
+      in a special comment line "# eof".
+
+   X.<class>.db  This optional file if present contains the RPSL objects
+      in X.db that are of class <class>.  The format of the file is same
+      as that of X.db.
+
+   X.transaction-label  This file contains a transaction-label object
+      that records the timestamp and the latest sequence number of the
+      repository at the time of the snapshot.
+
+   Each of these files can be optionally compressed uzing gzip.  This is
+   signified by appending the suffix .gz to the file name.  Each of
+   these files can optionally be PGP signed.  In this case, the detached
+   signature with ASCII armoring and platform-independent text mode is
+   stored in a file whose name is constructed by appending .sig to the
+   file name of the file being signed.
+
+   In order to construct a repository's contents from a snapshot, a
+   repository downloads these files.  After uncompressing and checking
+   signatures, the repository records these objects in its database.  No
+
+
+
+Villamizar, et al.          Standards Track                    [Page 24]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   RPS authorization/authentication is done on these objects.  The
+   transaction-label object provides the seed for the replication
+   protocol to receive the follow on transactions from this repository.
+   Hence, it is not crucial to download an up to the minute snapshot.
+
+   After successfully playing a snapshot, it is possible that a
+   repository may receive a transaction from a third repository that has
+   a dependency on an earlier version of one of the objects in the
+   snapshot.  This can only happen within the expire period of the
+   repository being downloaded, plus any possible network partition
+   period.  This dependency is only important if the repository wants to
+   re-verify RPS authorization/authentication.  There are three allowed
+   alternatives in this case.  The simplest alternative is for the
+   repository to accept the transaction and mark it with integrity "no-
+   auth".  The second choice is to only peer with trusted repositories
+   during this time period, and accept the transaction with the same
+   integrity as the trusted repository (possibly as "authorized").  The
+   most preferred alternative is not to download an up to the minute
+   snapshot, but to download an older snapshot, at minimum twice the
+   repositories expire time, in practice few days older.  Upon replaying
+   an older snapshot, the replication protocol will fetch the more
+   current transactions from this repository.  Together they provide the
+   necessary versions of objects to re-verify rps
+   authorization/authentication.
+
+7.6  Authenticating Operations
+
+   The "signature" and "repository-signature" meta-objects represent
+   signatures.  Where multiple of these objects are present, the
+   signatures should be over the original contents, not over other
+   signatures.  This allows signatures to be checked in any order.
+
+   A maintainer can also sign a transaction using several authentication
+   methods (some of which may be available in some repositories only).
+
+   In the case of PGP, implementations should allow the signatures of
+   the "signature" and "repository-signature" meta-objects to be either
+   the detached signatures produced by PGP or regular signatures
+   produced by PGP. In either case, ASCII armoring and platform-
+   independent text mode should be used.
+
+   Note that the RPSL objects themselves are not signed but the entire
+   transaction body is signed.  When exchanging transactions among
+   registries, the meta-objects (e.g.  "auth-dependency") prior to the
+   first "repository-signature" meta object in the redistributed text
+   are also signed over.
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 25]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   Transactions must remain intact, including the signatures, even if an
+   authentication method provided by the submitter is not used by a
+   repository handling the message.  An originating repository may chose
+   to remove clear text passwords signatures from a transaction, and
+   replace it with the keyword "clear-text-passwd" followed by the
+   maintainer's id.
+
+     signature: clear-text-passwd <maintainer-name>
+
+   Note that this does not make the system less secure since clear text
+   password is an indication of total trust to the originating
+   repository by the maintainer.
+
+   A repository may sign a transaction that it verified.  If at any
+   point the signature of a trusted repository is encountered, no
+   further authorization or authentication is needed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 26]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+A  Examples
+
+   RPSL provides an external representation of RPSL objects and
+   attributes.  An attribute is a name/value pair.  RPSL is line
+   oriented.  Line continuation is supported, however most attributes
+   fit on a single line.  The attribute name is followed by a colon,
+   then any amount of whitespace, then the attribute value.  An example
+   of the ASCII representation of an RPSL attribute is the following:
+
+       route:     140.222.0.0/16
+
+   An RPSL object is a set of attributes.  Objects are separated from
+   each other by one or more blank lines.  An example of a complete RPSL
+   object follows:
+
+       route:         140.222.0.0/16
+       descr:         ANS Communications
+       origin:        AS1673
+       member-of:     RS-ANSOSPFAGGREGATE
+       mnt-by:        ANS
+       changed:       tck@ans.net 19980115
+       source:        ANS
+
+A.1  Initial Object Submission and Redistribution
+
+   Figure 1 outlines the steps involved in submitting an object and the
+   initial redistribution from the authoritative registry to its flooding
+   peers.
+
+   If the authorization check requires objects from other repositories,
+   then the sequence numbers of the local copies of those databases is
+   required for mirrors to recheck the authorization.
+
+   To simply resubmit the object from the prior example, the submitter or
+   a client application program acting on the submitter's behalf must
+   submit a transaction.  The legacy method was to send PGP signed email.
+   The preferred method is for an interactive program to encapsulate a
+   request between "transaction-submit-begin" and
+   "transaction-submit-end" meta-objects and encapsulate that as a
+   signed block as in the following example:
+
+
+
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 27]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+    +--------------+
+    |  Transaction |
+    |  signed by   |
+    |  submitter   |
+    +--------------+
+           |
+           |  1
+           v
+    +---------------------+  2
+    |  Primary repository |---->+----------+
+    |  identified by      |     | database |
+    |  RPSL source        |<----+----------+
+    +---------------------+  3
+           |
+           |  4
+           v
+    +----------------+
+    |  Redistributed |
+    |  transaction   |
+    +----------------+
+
+    1.  submit object
+    2.  authorization check
+    3.  sequence needed for authorization
+    4.  redistribute
+
+   Figure 1:  Initial Object Submission and Redistribution
+
+
+
+    transaction-submit-begin:  ANS 1
+    response-auth-type:        PGP
+    transaction-confirm-type:  normal
+
+    route:         140.222.0.0/16
+    descr:         ANS Communications
+    origin:        AS1673
+    member-of:     RS-ANSOSPFAGGREGATE
+    mnt-by:        ANS
+    changed:       curtis@ans.net 19990401
+    source:        ANS
+
+    timestamp: 19990401 10:30:00 +08:00
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 28]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+    signature:
+    + -----BEGIN PGP SIGNATURE-----
+    + Version: PGP for Personal Privacy 5.0
+    + MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+    +
+    + iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+    + Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+    + Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+    + PGBIEN3/NlM=
+    + =c93c
+    + -----END PGP SIGNATURE-----
+
+    transaction-submit-end:    ANS 1
+
+   The signature covers the everything after the first blank line after
+   the "transaction-submit-begin" object to the last blank line before
+   the "signature" meta-object.  If multiple signatures are needed, it
+   would be quite easy to email this block and ask the other party to
+   add a signature-block and return or submit the transaction.  Because
+   of delay in obtaining multiple signatures the accuracy of the
+   "timestamp" cannot be strictly enforced.  Enforcing accuracy to
+   within the "expire" time of the database might be a reasonable
+   compromise.  The tradeoff is between convenience, allowing a longer
+   time to obtain multiple signatures, and increased time of exposure to
+   replay attack.
+
+   The ANS repository would look at its local database and make
+   authorization checks.  If the authorization passes, then the sequence
+   number of any other database needed for the authorization is
+   obtained.
+
+   If this operation was successful, then a confirmation would be
+   returned.  The confirmation would be of the form:
+
+    transaction-confirm:  ANS 1
+    confirmed-operation:  change route 140.222.0.0/16 AS1673
+    commit-status:        commit
+    timestamp:            19990401 10:30:10 +05:00
+
+A.2  Transaction Redistribution Encoding
+
+   Having passed the authorization check the transaction is given a
+   sequence number and stored in the local transaction log and is then
+   flooded.  The meta-object flooded to another database would be signed
+   by the repository and would be of the following form:
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 29]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+    transaction-label: ANS
+    sequence: 6666
+    timestamp: 19990401 13:30:10 +05:00
+    integrity: authorized
+
+    route:         140.222.0.0/16
+    descr:         ANS Communications
+    origin:        AS1673
+    member-of:     RS-ANSOSPFAGGREGATE
+    mnt-by:        ANS
+    changed:       curtis@ans.net 19990401
+    source:        ANS
+
+    timestamp: 19990401 10:30:00 +08:00
+
+    signature:
+    + -----BEGIN PGP SIGNATURE-----
+    + Version: PGP for Personal Privacy 5.0
+    + MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+    +
+    + iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+    + Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+    + Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+    + PGBIEN3/NlM=
+    + =c93c
+    + -----END PGP SIGNATURE-----
+
+    auth-dependency: ARIN
+    sequence: 555
+    timestamp: 19990401 13:30:08 +05:00
+
+    auth-dependency: RADB
+    sequence: 4567
+    timestamp: 19990401 13:27:54 +05:00
+
+    repository-signature: ANS
+    signature:
+    + -----BEGIN PGP SIGNATURE-----
+    + Version: PGP for Personal Privacy 5.0
+    + MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+    +
+    + iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+    + Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+    + Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+    + PGBIEN3/NlM=
+    + =c93c
+    + -----END PGP SIGNATURE-----
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 30]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   Note that the repository-signature above is a detached signature for
+   another file and is illustrative only.  The repository-signature
+   covers from the "transaction-label" meta-object (including) to the
+   last blank line before the first "repository-signature" meta-object
+   (excluding the last blank line and the "repository-signature"
+   object).
+
+A.3  Transaction Protocol Encoding
+
+    transaction-begin: 1276
+    transfer-method: plain
+
+    transaction-label: ANS
+    sequence: 6666
+    timestamp: 19990401 13:30:10 +05:00
+    integrity: authorized
+
+    route:         140.222.0.0/16
+    descr:         ANS Communications
+    origin:        AS1673
+    member-of:     RS-ANSOSPFAGGREGATE
+    mnt-by:        ANS
+    changed:       curtis@ans.net 19990401
+    source:        ANS
+
+    timestamp: 19990401 10:30:00 +08:00
+
+    signature:
+    + -----BEGIN PGP SIGNATURE-----
+    + Version: PGP for Personal Privacy 5.0
+    + MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+    +
+    + iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+    + Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+    + Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+    + PGBIEN3/NlM=
+    + =c93c
+    + -----END PGP SIGNATURE-----
+
+    auth-dependency: ARIN
+    sequence: 555
+    timestamp: 19990401 13:30:08 +05:00
+
+    auth-dependency: RADB
+    sequence: 4567
+    timestamp: 19990401 13:27:54 +05:00
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 31]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+    repository-signature: ANS
+    signature:
+    + -----BEGIN PGP SIGNATURE-----
+    + Version: PGP for Personal Privacy 5.0
+    + MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+    +
+    + iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+    + Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+    + Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+    + PGBIEN3/NlM=
+    + =c93c
+    + -----END PGP SIGNATURE-----
+
+   Before the transaction is sent to a peer, the repository prepends a
+   "transaction-begin" meta-object.  The value of the "transaction-
+   begin" attribute is the number of octets in the transaction, not
+   counting the "transaction-begin" meta-object and the first blank line
+   after it.
+
+   Separating transaction-begin and transaction-label objects enables
+   different encodings at different flooding peerings.
+
+A.4  Transaction Redistribution
+
+   The last step in Figure 1 was redistributing the submitter's
+   transaction through flooding (or later through polling).  Figure 2
+   illustrates the further redistribution of the transaction.
+
+   If the authorization check was repeated, the mirror may optionally
+   add a repository-signature before passing the transaction any
+   further.  A "signature" can be added within that block.  The previous
+   signatures should not be signed.
+
+   Figure 3 illustrates the special case referred to as a "lightweight
+   mirror".  This is specifically intended for routers.
+
+   The lightweight mirror must trust the mirror from which it gets a
+   feed.  This is a safe assumption if the two are under the same
+   administration (the mirror providing the feed is a host owned by the
+   same ISP who owns the routers).  The lightweight mirror simply checks
+   the signature of the adjacent repository to insure data integrity.
+
+
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 32]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+    +----------------+
+    |  Redistributed |
+    |  transaction   |
+    +----------------+
+           |
+           |  1
+           v
+    +--------------------+  2
+    |                    |---->+----------+
+    |  Mirror repository |     | database |
+    |                    |<----+----------+
+    +--------------------+  3
+           |
+           |  4
+           v
+    +------------------+
+    |+----------------+|
+    ||  Redistributed ||
+    ||  transaction   ||
+    |+----------------+|
+    |  Optional        |
+    |  signature       |
+    +------------------+
+
+    1.  redistribute transaction
+    2.  recheck authorization against full DB at the
+        time of the transaction using sequence numbers
+    3.  authorization pass/fail
+    4.  optionally sign then redistribute
+
+   Figure 2:  Further Transaction Redistribution
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 33]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+    +----------------+
+    |  Redistributed |
+    |  transaction   |
+    +----------------+
+           |  1
+           v
+    +--------------------+  2
+    |                    |---->+----------+
+    |  Mirror repository |     | database |
+    |                    |<----+----------+
+    +--------------------+  3
+           |  4
+           v
+    +----------------+
+    |  Redistributed |
+    |  transaction   |
+    +----------------+
+           |  5
+           v
+    +--------------------+
+    |  Lightweight       |  6  +----------+
+    |  Mirror repository |---->| database |
+    |  (router?)         |     +----------+
+    +--------------------+
+
+    1.  redistribute transaction
+    2.  recheck authorization against full DB at the
+        time of the transaction using sequence numbers
+    3.  authorization pass/fail
+    4.  sign and redistribute
+    5.  just check mirror signature
+    6.  apply change with no authorization check
+
+   Figure 3:  Redistribution to Lightweight Mirrors
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 34]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+B  Technical Discussion
+
+B.1  Server Processing
+
+   This document does not mandate any particular software design,
+   programming language choice, or underlying database or underlying
+   operating system.  Examples are given solely for illustrative
+   purposes.
+
+B.1.1  getting connected
+
+   There are two primary methods of communicating with a repository
+   server.  E-mail can be sent to the server.  This method may be
+   deprecated but at least needs to be supported during transition.  The
+   second method is preferred, connect directly to a TCP socket.
+
+   Traditionally the whois service is supported for simple queries.  It
+   might be wise to retain the whois port connection solely for simple
+   queries and use a second port not in the reserved number space for
+   all other operations including queries except those queries using the
+   whois unstructured single line query format.
+
+   There are two styles of handling connection initiation is the
+   dedicated daemon, in the style of BSD sendmail, or launching through
+   a general purpose daemon such as BSD inetd.  E-mail is normally
+   handled sequentially and can be handled by a front end program which
+   will make the connection to a socket in the process as acting as a
+   mail delivery agent.
+
+B.1.2  rolling transaction logs forward and back
+
+   There is a need to be able to easily look back at previous states of
+   any database in order to repeat authorization checks at the time of a
+   transaction.  This is difficult to do with the RIPE database
+   implementation, which uses a sequentially written ASCII file and a
+   set of Berkeley DB maintained index files for traversal.  At the very
+   minimum, the way in which deletes or replacements are implemented
+   would need to be altered.
+
+   In order to easily support a view back at prior versions of objects,
+   the sequence number of the transaction at which each object was
+   entered would need to be kept with the object.  A pointer would be
+   needed back to the previous state of the object.  A deletion would
+   need to be implemented as a new object with a deleted attribute,
+   replacing the previous version of the object but retaining a pointer
+   back to it.
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 35]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   A separate transaction log needs to be maintained.  Beyond some age,
+   the older versions of objects and the the older transaction log
+   entries can be removed although it is probably wise to archive them.
+
+B.1.3  committing or disposing of transactions
+
+   The ability to commit large transaction, or reject them as a whole
+   poses problems for simplistic database designs.  This form of commit
+   operation can be supported quite easily using memory mapped files.
+   The changes can be made in virtual memory only and then either
+   committed or disposed of.
+
+B.1.4  dealing with concurrency
+
+   Multiple connections may be active.  In addition, a single connection
+   may have multiple outstanding operations.  It makes sense to have a
+   single process or thread coordinate the responses for a given
+   connection and have multiple processes or threads each tending to a
+   single operation.  The operations may complete in random order.
+
+   Locking on reads is not essential.  Locking before write access is
+   essential.  The simplest approach to locking is to lock at the
+   database granularity or at the database and object type granularity.
+   Finer locking granularity can also be implemented.  Because there are
+   multiple databases, deadlock avoidance must be considered.  The usual
+   deadlock avoidance mechanism is to acquire all necessary locks in a
+   single operation or acquire locks in a prescribed order.
+
+B.2  Repository Mirroring for Redundancy
+
+   There are numerous reasons why the operator of a repository might
+   mirror their own repository.  Possibly the most obvious are
+   redundancy and the relative ease of disaster recovery.  Another
+   reason might be the widespread use of a small number of
+   implementations (but more than one) and the desire to insure that the
+   major repository software releases will accept a transaction before
+   fully committing to the transaction.
+
+   The operation of a repository mirror used for redundancy is quite
+   straightforward.  The transactions of the primary repository host can
+   be immediately fed to the redundant repository host.  For tighter
+   assurances that false positive confirmations will be sent, as a
+   matter of policy the primary repository host can require commit
+   confirmation before making a transaction sequence publicly available.
+
+   There are many ways in which the integrity of local data can be
+   assured regardless of a local crash in the midst of transaction disk
+   writes.  For example, transactions can be implemented as memory
+
+
+
+Villamizar, et al.          Standards Track                    [Page 36]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   mapped file operations, with disk synchronization used as the local
+   commit mechanism, and disposal of memory copies of pages used to
+   handle commit failures.  The old pages can be written to a separate
+   file, the new pages written into the database.  The transaction can
+   be logged and old pages file can then be removed.  In the event of a
+   crash, the existence of a old pages file and the lack of a record of
+   the transaction completing would trigger a transaction roll back by
+   writing the old pages back to the database file.
+
+   The primary repository host can still sustain severe damage such as a
+   disk crash.  If the primary repository host becomes corrupted, the
+   use of a mirror repository host provides a backup and can provide a
+   rapid recovery from disaster by simply reversing roles.
+
+   If a mirror is set up using a different software implementation with
+   commit mirror confirmation required, any transaction which fails due
+   a software bug will be deferred indefinitely allowing other
+   transactions to proceed rather than halting the remote processing of
+   all transactions until the bug is fixed everywhere.
+
+B.3  Trust Relationships
+
+   If all repositories trust each other then there is never a need to
+   repeat authorization checks.  This enables a convenient interim step
+   for deployment prior to the completion of software supporting that
+   capability.  The opposite case is where no repository trusts any
+   other repository.  In this case, all repositories must roll forward
+   transactions gradually, checking the authorization of each remote
+   transaction.
+
+   It is likely that repositories will trust a subset of other
+   repositories.  This trust can reduce the amount of processing a
+   repository required to maintain mirror images of the full set of
+   data.  For example, a subset of repositories might be trustworthy in
+   that they take reasonable security measures, the organizations
+   themselves have the integrity not to alter data, and these
+   repositories trust only a limited set of similar repositories.  If
+   any one of these repositories receives a transaction sequence and
+   repeats the authorization checks, other major repositories which
+   trusts that repository need not repeat the checks.  In addition,
+   trust need not be mutual to reap some benefit in reduced processing.
+
+   As a transaction sequence is passed from repository to repository
+   each repository signs the transaction sequence before forwarding it.
+   If a receiving repository finds that any trusted repository has
+   signed the transaction sequence it can be considered authorized since
+   the trusted repository either trusted a preceding repository or
+   repeated the authorization checks.
+
+
+
+Villamizar, et al.          Standards Track                    [Page 37]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+B.4  A Router as a Minimal Mirror
+
+   A router could serve as a minimal repository mirror.  The following
+   simplifications can be made.
+
+   1. No support for repeating authorization checks or transaction
+      authentication checks need be coded in the router.
+
+   2. The router must be adjacent only to trusted mirrors, generally
+      operated by the same organization.
+
+   3. The router would only check the authentication of the adjacent
+      repository mirrors.
+
+   4. No support for transaction submission or query need be coded in
+      the router.  No commit support is needed.
+
+   5. The router can dispose of any object types or attributes not
+      needed for configuration of route filters.
+
+   The need to update router configurations could be significantly
+   reduced if the router were capable of acting as a limited repository
+   mirror.
+
+   A significant amount of non-volatile storage would be needed.  There
+   are currently an estimated 100 transactions per day.  If storage were
+   flash memory with a limited number of writes, or if there were some
+   other reason to avoid writing to flash, the router could only update
+   the non-volatile copy every few days.  A transaction sequence request
+   can be made to get an update in the event of a crash, returning only
+   a few hundred updates after losing a few days of deferred writes.
+   The routers can still take a frequent or continuous feed of
+   transactions.
+
+   Alternately, router filters can be reconfigured periodically as they
+   are today.
+
+B.5  Dealing with Errors
+
+   If verification of an authorization check fails, the entire
+   transaction must be rejected and no further advancement of the
+   repository can occur until the originating repository corrects the
+   problem.  If the problem is due to a software bug, the offending
+   transaction can be removed manually once the problem is corrected.
+   If a software bug exists in the receiving software, then the
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 38]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   transaction sequence is stalled until the bug is corrected.  It is
+   better for software to error on the side of denying a transaction
+   than acceptance, since an error on the side of acceptance will
+   require later removal of the effects of the transaction.
+
+C  Deployment Considerations
+
+   This section described deployment considerations.  The intention is
+   to raise issues rather than to provide a deployment plan.
+
+   This document calls for a transaction exchange mechanism similar to
+   but not identical to the existing "near real time mirroring"
+   supported by the code base widely used by the routing registries.  As
+   an initial step, the transaction exchange can be implemented without
+   the commit protocol or the ability to recheck transaction
+   authorization.  This is a fairly minimal step from the existing
+   capabilities.
+
+   The transition can be staged as follows:
+
+   1. Modify the format of "near real time mirroring" transaction
+      exchange to conform to the specifications of this document.
+
+   2. Implement commit protocol and confirmation support.
+
+   3. Implement remote recheck of authorization.  Prior to this step all
+      repositories must be trusted.
+
+   4. Allow further decentralization of the repositories.
+
+D  Privacy of Contact Information
+
+   The routing registries have contained contact information.  The
+   redistribution of this contact information has been a delicate issue
+   and in some countries has legal implications.
+
+   The person and role objects contain contact information.  These
+   objects are referenced by NIC-handles.  There are some attributes
+   such as the "changed" and "notify" attributes that require an email
+   address.  All of the fields that currently require an email address
+   must also accept a NIC-handle.
+
+   The person and role objects should not be redistributed by default.
+   If a submission contains an email address in a field such as a
+   changed field rather than a NIC-handle the submitter should be aware
+   that they are allowing that email address to be redistributed and
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 39]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+   forfeiting any privacy.  Repositories which do not feel that prior
+   warnings of this forfeiture are sufficient legal protection should
+   reject the submission requesting that a NIC-handle be used.
+
+   Queries to role and person objects arriving at a mirror must be
+   referred to the authoritative repository where whatever
+   authentication, restrictions, or limitations deemed appropriate by
+   that repository can be enforced directly.
+
+   Software should make it possible to restrict the redistribution of
+   other entire object types as long as those object types are not
+   required for the authorization of additions of other object types.
+   It is not possible to redistribute objects with attributes removed or
+   altered since this would invalidate the submitter's signature and
+   make subsequent authentication checks impossible.  Repositories
+   should not redistribute a subset of the objects of a given type.
+
+   Software should also not let a transaction contain both
+   redistributable (e.g.  policy objects) and non-redustributable
+   objects (e.g.  person) since there is no way to verify the signature
+   of these transactions without the non-redustributable objects.
+
+   When redistributing legacy data, contact information in attributes
+   such as "changed" and "notify" should be stripped to maintain
+   privacy.  The "integrity" attribute on these objects should already
+   be set to "legacy" indicating that their origin is questionable, so
+   the issue of not being able to recheck signatures is not as
+   significant.
+
+References
+
+   [1]  Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
+        Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
+        Policy Specification Language", RFC 2622, June 1999.
+
+   [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]  Villamizar, C., Alaettinoglu, C., Meyer, D. and S. Murphy,
+        "Routing Policy System Security", RFC 2725, June 1999.
+
+   [4]  Zsako, J., "PGP Authentication for RIPE Database Updates", RFC
+        2726, December 1999.
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 40]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+Security Considerations
+
+   An authentication and authorization model for routing policy object
+   submission is provided by [3].  Cryptographic authentication is
+   addressed by [4].  This document provides a protocol for the exchange
+   of information among distributed routing registries such that the
+   authorization model provided by [3] can be adhered to by all
+   registries and any deviation (hopefully accidental) from those rules
+   on the part of a registry can be identified by other registries or
+   mirrors.
+
+Authors' Addresses
+
+   Curtis Villamizar
+   Avici Systems
+   EMail: curtis@avici.com
+
+
+   Cengiz Alaettinoglu
+   ISI
+   EMail: cengiz@ISI.EDU
+
+
+   Ramesh Govindan
+   ISI
+   EMail: govindan@ISI.EDU
+
+
+   David M. Meyer
+   Cisco
+   EMail: dmm@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Villamizar, et al.          Standards Track                    [Page 41]
+
+RFC 2769           Routing Policy System Replication       February 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 42]
+