diff options
Diffstat (limited to 'doc/rfc/rfc2769.txt')
| -rw-r--r-- | doc/rfc/rfc2769.txt | 2355 |
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] + |