Internet Engineering Task Force Curtis Villamizar INTERNET-DRAFT UUNET draft-ietf-rps-dist-02.txt Cengiz Alaettinoglu ISI Ramesh Govindan ISI David M. Meyer Cisco June 24, 1999 Distributed Routing Policy System Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference mate- rial or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (June 24, 1999). All Rights Re- served. Abstract The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of ex- INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 changing information needed to address many issues on 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 internet-draft addresses the need to assure integrity of the data by proposing an authenti- cation and authorization model. This document addresses the need to distribute data over multiple repositories and delegate author- ity for data subsets to multiple repositories without compromising the authorization model established in Routing Policy System Security internet-draft. 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 reposito- ries. Two methods of authenticating the routing registry information have been proposed. authorization and authentication checks on transactions: The in- tegrity of the routing registry data is insured by repeating au- thorization checks as transactions are processed. As transactions are flooded each remote registry has the option to repeat the au- thorization 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 Villamizar,Alaettinoglu,Govindan,Meyer Expires December 24, 2000 [Page 2] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 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 autho- rization 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 au- thorization references back to falsified 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 au- thentication 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 authori- tative source for any objects. From a protocol standpoint, reposito- ries and mirrors appear identical in the flooding topology. Either a repository or a mirror may recheck all or a subset of trans- actions 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 autho- rization 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 autho- rization 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 sig- nature 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 Villamizar,Alaettinoglu,Govindan,Meyer Expires December 24, 2000 [Page 3] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 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 se- lectable 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 mes- sage with information needed for authentication derived from the mail headers. Merit has slightly modified this using the PGP signed por- tion 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 authoriza- tion 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 re- trieve back revisions of objects. How this is accomplished is a mat- ter 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 encapsu- lation 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 authentica- tion from authorization. Villamizar,Alaettinoglu,Govindan,Meyer Expires December 24, 2000 [Page 4] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 o Authentication is the means to determine who is attempting to make a change. o Authorization is the determination of whether a transaction pass- ing 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. 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 restric- tions 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 prop- agate 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 at- tribute is used to determine if a repository must be updated before a local transaction can 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 re- sponding to queries. The ``submit-address'' attribute provides a host name and a port number used to submit objects to the repository. The Villamizar,Alaettinoglu,Govindan,Meyer Expires December 24, 2000 [Page 5] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 ``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 repos- itory database and can be retrieved with ordinary queries. Objects consist of ``attributes'', which are name/value pairs. 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 encapsula- tions 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 repos- itories 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.ripe.net 43 response-auth-type: rsa-pubkey some-incredibly-long-public-key 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 Villamizar,Alaettinoglu,Govindan,Meyer Expires December 24, 2000 [Page 6] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 mnt-by: maint-ripe-db expire: 0000 04:00:00 heartbeat-rate: 0000 01:00:00 ... remarks: admin and technical contact, etc source: IANA 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. The attributes of the repository object are listed below. repository key mandatory single unique 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 host name and a port number used to direct queries. Optional fields may follow the port number at a later time and should be ignored. Alternately a URL format may be used. The special protocol identified ``rps-query'' can be Villamizar,Alaettinoglu,Govindan,Meyer Expires December 24, 2000 [Page 7] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 used in URL format. response-auth-type This attribute provides the authentication types that may be used by the repository when responding to queries. submit-address This attribute provides a host name and a port num- ber used to submit objects to the repository. Optional fields may follow the port number at a later time and should be ignored. Al- ternately a URL format may be used. submit-auth-type This attribute provides the authentication types that may be used by the repository when responding to queries. 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. heartbeat-interval Heartbeat meta-objects are sent by this repos- itory 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 near real time flooding is temporarily not operational, objects should be considered non-authoritative after this inter- val, 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. 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 natu- ral 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 Villamizar,Alaettinoglu,Govindan,Meyer Expires December 24, 2000 [Page 8] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 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 grand- fathered 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. 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 pro- vide 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 (they would be overridden by the RIPE copy). 5.3 integrity attribute The ``integrity'' attribute can be contained in any RPSL object type. It is intended solely as a means to facilitate a transition period during when 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 authoriza- Villamizar,Alaettinoglu,Govindan,Meyer Expires December 24, 2000 [Page 9] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 tion model. The data is highly suspect. no-auth: This data was added to a repository during an initial tran- sition use of an authorization model but authorization was with a maintainer that did not have a ``referral-by'' attribute, or used a discouraged weak form of authentication, or relied upon other objects for authorization 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 autho- rization. Had it been doing so, authorization would have failed. This attribute may be added by a repository that is mirroring be- fore placing the object in its local storage, or can add this at- tribute to an encapsulating meta-object used to further propagate the transaction. If the failure to enforce authorization is in- tentional 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 trans- action. authorized: Authorization checks were passed. The maintainer con- tained 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 ``autho- rized''. 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 autho- rized 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 autho- rization would remain but would be marked as candidates for replace- ment. 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. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 10] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 Initial submission of transactions: Transactions may include addi- tions, 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 inter- actions between registries is the redistribution of transactions. There are a number of ways to redistribute transactions. Transac- tions can also be rescinded. This is discussed in Section 6.2. Queries: Query interactions are outside the scope of this document. Rescinding Transactions Although it is hoped that the feature is never needed, it may be necessary to rescind transactions (Sec- tion 6.3). Transaction Commit and Confirmation: Repositories may optionally im- plement a commit protocol and a completion indication that gives the submitter of a transaction a response that indicates that a 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.4. 6.1 Initial Transaction Submission The simplest form of transaction submission is an object or set of objects submitted with RFC--822 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 sub- mitter 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 de- sired, then an external program can provide the email interface. The encapsulation of a transaction submission and response is de- scribed in detail in Section 7. 6.2 Redistribution of Transactions Redistribution of transactions can be accomplished using three types of requests for redistribution of transactions. 1. A repository snapshots 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. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 11] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 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 Rescinding Transactions Rescinding a transaction is a manual intervention. The administrators of a repository may find it necessary to request that a specific set of transactions be removed. Database mirrors would have to roll back the entire database to the first transaction being rescinded and then roll forward the transaction log from that point forward. Authoriza- tions in other repositories may be affected. There are many reasons for having to rescind a transaction whose cause is outside the control of the operator of the repository. For exam- ple, a disgruntled employee at a client of the repository may remove all authorization from that clients database objects. There may be opportunities for malicious entries in objects for which there is no authorization hierarchy (See [3]). An example is the anonymous regis- tration of falsified person objects or libelous or obscene person or role objects. In addition, mistakes or program bugs are inevitable. The most compelling reason to support a rescind is the possibility of a security breach at the repository that results in theft of identity of the repository and falsified transactions. The rescind feature is one that needs to be included but the repositories hope to never need. 6.4 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 ini- tial transaction submission to another repository to confirm that they have been able to advance the transaction sequence up to the se- quence 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 Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 12] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 rechecked by the responding repository and passed or that the respond- ing 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 sub- mitter 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 char- acters (space, tab, or line continuation) and followed by the value. Within a value all whitespace is equivalent to a single space. Line continuation is supported by a backslash at the end of a line or the following line beginning with whitespace. When transferred externally attributes are generally broken into shorter lines using line con- tinuation though this is not a requirement. An object is externally represented as a series of attributes. Objects are separated by blank lines. As an example, there are about 80 attribute types in the current RIPE schema and about 15 object types. Some of the attributes are manda- tory in certain objects. Some attributes may appear multiple times. One or more attributes may form a key. Some attributes or sets of attributes may be required to be unique. Some of the attributes may reference a key field in an object type and may be required to be a valid reference. Some attributes may be used in inverse lookups. A review of the entire RIPE or RPSL schema would be too lengthy to include here. Only the differences in the schema are described. Interactions with the registry either use a legacy format or are encapsulated using sets of name and value pairs that are formated like RPSL objects. These are not part of RPSL and are referred to as ``meta-objects''. The meta-objects serve mostly as delimiters to the transactions and to carry information about the type of 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. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 13] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 Merit has added the pgp-from authentication method to the RADB (re- placed 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. The ``timestamp'' meta-object contains a single attribute: timestamp This attribute is mandatory and single-valued. This at- tribute specifies the time at which the user submits the transac- tion 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 be accepting transactions with timestamps within its expire window. Each ``signature'' meta-object contains a single attribute: signature This attribute is mandatory and single-valued. This at- tribute, 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 au- thentication), the signature must include all text upto (but not including) the first ``signature'' meta-object. The blank lines in front of the ``signature'' meta-object are also included. 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 ``times- tamp'' and ``signature'' meta-objects, constitute the ``submitted text'' of the transaction. The protocol used for submitting a transaction, and for receiving con- firmation of locally committed transactions, is not specified in this document. This protocol may define additional encapsulations around Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 14] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 the submitted text. The rest of this section gives an example of one such protocol. Implementations are free to choose another encapsula- tion. 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 con- nects to the socket. A socket connection must use the ``transaction- submit-begin'' and ``transaction-submit-end'' delimiters but can re- quest a legacy style confirmation. Use of the email interface is discouraged and the email interface will eventually be deprecated. 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 identi- fier that must be unique over the course of the socket connection. response-auth-type This attribute is optional and multiple. The re- mainder 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 at- tribute by the same name. It must contain the same database name and identifier as the corresponding ``transaction-submit-begin'' at- tribute. 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 contains additional detail. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 15] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 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 con- tains the database name and identifier associated with the transac- tion. confirmed-operation This attribute is optional and multiple. It contains one of the keywords ``add'', ``delete'' or ``modify'' fol- lowed 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 ``timeout'', ``error'', or ``commit''. The ``error'' keyword may be followed by an optional text string. 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 trans- action 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 mir- rors. In this section, we first describe how a repository may encapsulate the submitted text of a transaction. We then describe the proto- col 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 trans- action using methods described in [3]. Before redistributing a transaction, the originating repository must encapsulate the submitted text of the transaction with several meta- objects, which are described below. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 16] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 The originating repository must prepend the submitted text with ex- actly one ``transaction-label'' meta-object. This meta-object con- tains 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 rep- resents 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 as- signed by the originating repository to the transaction. Succes- sive 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 at- tribute 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 ``autho- rized''. If absent, the integrity is considered to be ``autho- rized''. 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 objects were used by the originating registry to authenticate the submitted text. 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 autho- rize/authenticate this transaction. 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 transac- tion. 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. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 17] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 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. signature This attribute is mandatory and single-valued. This at- tribute, a block of free text, contains the repository's signature corresponding to the authentication method used for the transac- tion. When the authentication method is a cryptographic hash (as in PGP-based authentication), the signature must include all text upto (but not including) the ``repository-signature'' meta-object. Blank lines in front of the ``repository-signature'' meta-object are also included. A repository must reject a redistributed transaction that does not include any ``repository-signature'' meta-object. The transaction-label, the submitted text, the dependency objects, and the repository's signature together constitute what we call the ``redistributed text''. In preparation for redistributing the transaction to other reposito- ries, 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 re- distributed text. transfer-method This attribute is optional and single-valued. Its value is one of: ``gzip'', ``uuencode'', ``base50'', ``radix64'', or ``plain''. The value of the attribute describes the kind of text encoding that the repository has performed on the redis- tributed text. If this attribute is not specified, its value is assumed to be ``plain''. An implementation must be capable of decoding each of these text encodings, but should support both ``gzip'' and ``plain'' encodings. The ``transaction-begin'' meta-object and the transformed redis- tributed text constitute what we call the ``transmitted text''. The Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 18] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 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 de- code the original redistributed text according to the value of the transfer-method attribute specified in the ``transaction-begin'' meta-object. 2. It should verify that the signature of the originating repository matches the first ``repository-signature'' meta-object in the re- distributed text following the ``auth-dependency'' meta-objects. 3. It may check whether any subsequent ``repository-signature'' meta- objects were generated by a trusted repository. If so, this indi- cates that the trusted repository marked the transaction successful (see below). The repository may also mark the transaction success- ful, and skip the remaining steps. 4. It should verify the syntactic correctness of the transaction. An implementation may allow configurable levels of syntactic confor- mance with RPSL [1]. This enables RPSL extensions to be incremen- tally deployed in the distributed registry scheme. 5. If not all previous (i.e., those with a lower sequence number) transactions from the same repository have been received or com- pletely processed, the repository must ``hold'' this transaction. 6. The repository must authorize and authenticate this transaction. To do this, it may need to reference objects and transactions from one or more other repositories. If these objects are not avail- able, 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 transac- tion, the repository must not use an object from a repository not mentioned in an ``auth-dependency'' meta-obect. 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. To the redistributed text of a successful transaction, a repository may append a ``repository-signature'' meta-object. This indicates that that repository has verified the transaction's integrity is ``au- thorized'', even if the originator marked the transaction's integrity ``no-auth''. The signature includes the original (i.e., untrans- formed) redistributed text. The original redistributed text, together Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 19] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 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 that performed by the originating repository (except that the reposi- tory 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 be- longing 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 con- tains the name of the database whose transactions are being re- quested. 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 Sec- tion 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 re- quested. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 20] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 sequence-begin This attribute is optional and mandatory. It con- tains 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 mir- rors 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. 7.3.2 Heartbeat Processing Each repository that has originated at least one transaction must pe- riodically 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'' spec- ifies 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 min- utes 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 message, the repository must silently discard the heartbeat message. Otherwise, it must record the timestamp and sequence number in the Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 21] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 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 recip- ient, 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.4). 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 be- ing 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 trans- action. If so, it must send a ``commit-response'' meta-object to the requester. This meta-object has three attributes: commit-response This attribute is mandatory and single. It contains Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 22] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 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 ``timeout'', ``error'', or ``commit''. The ``error'' keyword may be followed by an optional text string. 7.5 Database Snapshot A database snapshot provides a complete copy of a database. It is intended only for repository initialization and and disaster recovery. A database snapshot request is represented by a ``snapshot-request'' meta-object. The ``snapshot-request'' meta-object may contain the the following attributes. snapshot-request This attribute is mandatory and single. It contains the database name of the database being requested. A database snapshot is returned. The database snapshot is delim- ited by a ``snapshot-begin'' and ``snapshot-end'' meta-object. The ``snapshot-begin'' meta-object may contain the following attributes. snapshot-begin This attribute is mandatory and single. It contains the database name and sequence number of the database snapshot be- ing returned. transfer-method This attribute is optional and single. It con- tains one or more of the following keywords ``gzip'', ``uuencode'', ``base50'', ``radix64''. A byte count may follow. timestamp This attribute is mandatory and single. It contains the time at which the snapshot was generated. The format of this at- tribute is ``YYYYMMDD hh:mm:ss [+/-]xx:yy'', where ``YYYY'' speci- fies 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 min- utes respectively that that timestamp is ahead or behind UTC. The ``snapshot-end'' meta-object contains a single attribute by the same name containing the same database name and sequence number pro- vided in the corresponding ``snapshot-begin''. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 23] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 The body of the snapshot is the set of objects in the form normally exchanged as printed RPSL objects. Each object is separated by a blank line. No signatures are provided except the signature on entire database snapshot from the repository providing the snapshot. The entire body may be compressed and then ASCII encoded. If the body is compressed but not ASCII encoded the last word of the transfer-method attribute value should be a byte count allowing a binary transfer to be used. If a binary transfer is used, the ``snapshot-begin'' meta- object block should be followed by exactly one empty line, then the binary data, then a trailing pair of newline characters (two line- feeds, not linefeed and carriage return). 7.5.1 Canceling Operations A request can be made to cancel most operations. Implementation of this feature is optional. The most common would be to cancel a ``query'' which is returning too much information or cancel a long running operation like a ``unicast-mirror-request''. A ``cancel-operation'' meta object contains only an attribute by the same name. The attribute contains the operation type represented by the key attribute name in the request without the trailing ``-begin''. The remainder of the ``cancel-operation'' attribute contains the key field of the request. When an operation is canceled a ``cancel-confirm'' meta-object is re- turned. Any response in progress is ended by the ``cancel-confirm'' and a ``-end'' meta-object should not be expected. The ``cancel- confirm'' attribute contains the same operation type and key field as the corresponding ``cancel-operation''. 7.6 Authenticating Operations The ``signature'' and ``repository-signature'' meta-objects represent detached signatures. Where multiple of these objects are present, the signatures should be over the original contents, not over other de- tached 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, the attributes of the ``signature'' and ``repository-signature'' meta-objects are the attributes contained in a detached signature file produced by PGP. Note that the RPSL objects themselves are not signed but the entire transaction body is signed. When exchanging transactions among reg- Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 24] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 istries, the meta-objects (e.g. ``auth-dependency'') prior to the first ``repository-signature'' meta object in the redistributed text are also signed over. 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 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 au- thorization or authentication is needed. A Examples RPSL provides an external representation of RPSL objects and at- tributes. An attribute is a name/value pair. RPSL is line oriented. Line continuation is supported, however most attributes fit on a sin- gle 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 Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 25] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 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. +--------------+ | 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 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- Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 26] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 end'' meta-objects and encapsulate that as a signed block as in the following example: 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 103000 +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----- transaction-submit-end: ANS 1 The signature covers the everything after the first blank line after the ``transaction-submit-begin'' to the line containing the ``sig- nature'' 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 de- lay in obtaining multiple signatures the accuracy of the ``timestamp'' cannot be strictly enforced. Enforcing accuracy to within the ``ex- pire'' 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 autho- rization checks. If the authorization passes, then the sequence num- ber of any other database needed for the authorization is obtained. If this operation was successful, then a confirmation would be re- Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 27] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 turned. The confirmation would be of the form: transaction-confirm: ANS 1 confirmed-operation: change route 140.222.0.0/16 AS1673 commit-status: commit date-time-stamp: 19990401 103010 +05:00 Note that this transaction could be replayed. The only protection is the ``timestamp'' attribute on the transaction. Figure 2 provides better protection against replay. The repository returns the submis- sion with a sequence number to be resigned by the submitter. +--------------+ | Transaction | | signed by | | submitter | +--------------+ |^| ||| 1 v|v +---------------------+ 2 | Primary repository |---->+----------+ | identified by | | database | | RPSL source |<----+----------+ +---------------------+ 3 | | 4 v +----------------+ | Redistributed | | transaction | +----------------+ 1. submit object return to submitter sign transaction 2. authorization check 3. sequence needed for authorization 4. redistribute Figure 2: Alternate Initial Object Submission In Figure 2 the submitter is protected against the possibility of the repository replaying a submission later or a snooper replaying the submission. This method is not specified in this document for two reasons. One is that if the ``date-time-stamp'' attribute is beyond Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 28] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 the ``expire'' period for the database, the authorization would be rejected. The other is that the sequence number would have to be re- served and a failure to reply with a resigned submission would halt database processing for some timeout period. An indefinite exposure to replay is present if the PGP signed email method of submission is used unless accuracy of the date stamp in the ``changed'' attribute is required. This would limit the replay window to approximately a day. A.2 Transactin Redistribution Encoding Having passed the authorization check the transaction is given a se- quence 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: transaction-label: ANS sequence: 6666 timestamp: 19990401 133010 +05:00 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 103000 +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 133008 +05:00 Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 29] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 auth-dependency: RADB sequence: 4567 timestamp: 19990401 132754 +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----- Note that the repository-signature above is a detached signature for another file and is illustrative only. The repository-signature cov- ers from the ``transaction-label'' meta-object (including) to the first ``repository-signature'' meta-object (excluding). A.3 Transactin Protocol Encoding transaction-begin: 1276 transfer-method: plain transaction-label: ANS sequence: 6666 timestamp: 19990401 133010 +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 103000 +08:00 signature: + -----BEGIN PGP SIGNATURE----- + Version: PGP for Personal Privacy 5.0 + MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI + Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 30] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 + iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U + Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX + Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv + PGBIEN3/NlM= + =c93c + -----END PGP SIGNATURE----- auth-dependency: ARIN sequence: 555 timestamp: 19990401 133008 +05:00 auth-dependency: RADB sequence: 4567 timestamp: 19990401 132754 +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----- 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 trans- action through flooding (or later through polling). Figure 3 illus- trates 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. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 31] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 +----------------+ | 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 3: Further Transaction Redistribution Figure 4 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 admin- istration (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. A.5 Optional Commit and Confirm This section needs to be reworked. In Figure 4 the full commit and confirm cycle is shown. Included is the extra initial submission ex- change for added protection against replay previous shown in Figure 2. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 32] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 +----------------+ | 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 4: Redistribution to Lightweight Mirrors Redistribution differs in that one or more repositories will receive the transaction encapsulated in a commit request. The commit request would be of the following form: signed-block-begin: ANS::PGPKEY-DEADBEEF 124 signature-block: PGP version: PGPfreeware 5.0i for non-commercial use signature: iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 33] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 +--------------+ | Transaction | | signed by | | submitter | +--------------+ |^| ^ ||| 1 | 6 v|v | +---------------------+ 2 | Primary repository |---->+----------+ | identified by | | database | | RPSL source |<----+----------+ +---------------------+ 3 | ^ | 4 | 5 v | +----------------+ | Redistributed | | transaction | +----------------+ 1. submit object return to submitter sign transaction 2. authorization check 3. sequence needed for authorization 4. redistribute 5. mirror confirms 6. repository confirms Figure 5: Optional Commit and Confirm PGBIEN3/NlM= =c93c mirror-request-begin: ANS 666 date-time-stamp: 19990401 103000 signed-block-begin: ANS::PGPKEY-DEADBEEF 123 signature-block: PGP version: PGPfreeware 5.0i for non-commercial use signature: iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv PGBIEN3/NlM= =c93c Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 34] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 transaction-begin: ANS 666 signed-block-begin: ANS::PGPKEY-3EBC5F29 1 signature-block: PGP version: PGPfreeware 5.0i for non-commercial use signature: iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv PGBIEN3/NlM= =c93c transaction-submit-begin: ANS 1 response-auth-type: PGP date-time-stamp: 19990401 103000 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 transaction-submit-end: ANS 1 signed-block-end: ANS::PGPKEY-3EBC5F29 1 transaction-end: ANS 666 signed-block-end: ANS::PGPKEY-DEADBEEF 123 mirror-request-end: ANS 666 signed-block-end: ANS::PGPKEY-DEADBEEF 124 The confirmation can be returned to the submitter when one of the repositories that was sent a commit request returns a commit comple- tion. This would be of the form: commit-response: ANS sequence: 666 commit-status: commit date-time-stamp: 19990401 103001 Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 35] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 In the event of a disk crash, the repository has already successfully flooded the transaction before sending the confirm back to the submit- ter. If a mirror is under the same administration, the repository can recover from disk and roll forward the transactions from the mirror before resuming operation. B Technical Discussion B.1 Server Processing This document does not mandate any particular software design, pro- gramming language choice, or underlying database or underlying operat- ing 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 dep- recated 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 dedi- cated 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 imple- mentation, which uses a sequentially written ASCII file and a set of Berkeley DB maintained index files for traversal. At the very min- imum, the way in which deletes or replacements are implemented would need to be altered. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 36] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 In order to easily support a view back at prior versions of objects, the sequence number of the transaction at which each object was en- tered 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, re- placing the previous version of the object but retaining a pointer back to it. A separate transaction log needs to be maintained. Beyond some age, the older versions of objects and the the older transaction log en- tries 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 commit- ted 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 connec- tion 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 es- sential. 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 mul- tiple 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 mir- ror 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 soft- ware releases will accept a transaction before fully committing to the Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 37] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 transaction. This may avoid the need to rescind transactions in the face of a newly discovered bug. 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 as- surances 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 as- sured regardless of a local crash in the midst of transaction disk writes. For example, transactions can be implemented as memory mapped file operations, with disk synchronization used as the local commit mechanism, and disposal of memory copies of pages used to handle com- mit 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 transac- tion 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 transac- tions until the bug is fixed everywhere or the offending transaction is rescinded. 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 trans- actions gradually, checking the authorization of each remote transac- tion. It is likely that repositories will trust a subset of other reposi- tories. This trust can reduce the amount of processing a repository required to maintain mirror images of the full set of data. For exam- ple, a subset of repositories might be trustworthy in that they take reasonable security measures, the organizations themselves have the Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 38] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 integrity not to alter data, and these repositories trust only a lim- ited 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 re- peat 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. 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 au- thentication checks need be coded in the router. 2. The router must be adjacent only to trusted mirrors, generally op- erated 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 re- duced 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. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 39] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 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 trans- action 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 transaction sequence is stalled until the bug is corrected. It is better for software to er- ror on the side of denying a transaction than acceptance, since an error on the side of acceptance will require rescinding transactions and rolling forward only those that were valid. 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'' sup- ported 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 ex- change 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 redis- tribution of this contact information has been a delicate issue an in Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 40] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 some countries has legal implications. The person and role objects contain contact information. These ob- jects are referenced by NIC-handles. There are some attributes such as the "changed" and "notify" attributes that require an email ad- dress. 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 forfeiting any privacy. Repositories which do not feel that prior warnings of this forfeiture are sufficient legal protection should reject the submis- sion requesting that a NIC-handle be used. Queries to role and person objects arriving at a mirror must be re- ferred 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 re- quired 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 redis- tributable (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] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, and C. Villamizar. Routing Policy Specification Language (RPSL). Technical Report RFC 2280, Internet Engineering Task Force, 1998. ftp://ftp.isi.edu/in-notes/rfc2280.txt. [2] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu. Representation of IP Routing Policies in a Routing Registry (ripe-81++). Technical Report RFC 1786, Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 41] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 Internet Engineering Task Force, 1995. ftp://ftp.isi.edu/in- notes/rfc1786.txt. [3] David Meyer, Curtis Villamizar, Cengiz Alaettinoglu, and S. Mur- phy. Routing Policy System Security. Internet Draft (Work in Progress) draft-ietf-rps-auth-03, Internet Engineering Task Force, 4 1999. ftp://ftp.isi.edu/internet-drafts/draft-ietf- rps-auth-03.txt. [4] Janos Zsako. PGP authentication for RIPE database updates. Internet Draft (Work in Progress) draft-ietf-rps-dbsec- pgp-authent-01, Internet Engineering Task Force, 4 1999. ftp://ftp.isi.edu/internet-drafts/draft-ietf-rps-dbsec-pgp- authent-01.txt. Security Considerations An authentication and authorization model for routing policy object submission is provided by [3]. Cryptographic authentication is ad- dressed by [4]. This document provides a protocol for the exchange of information among distributed routing registries such that the autho- rization 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. Author's Addresses Curtis Villamizar Cengiz Alaettinoglu Avici Systems ISI Ramesh Govindan David M. Meyer ISI Cisco Full Copyright Statement Copyright (C) The Internet Society (June 24, 1999). All Rights Re- served. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 42] INTERNET-DRAFT Distributed Routing Policy System June 24, 1999 or assist in its implmentation 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 in- cluded on all such copies and derivative works. However, this doc- ument itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other In- ternet 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 ENGINEER- ING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUD- ING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Villamizar,Alaettinoglu,Govindan,MeyerExpires December 24, 2000 [Page 43]