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
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:
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
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.
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.
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:
+--------------+
| 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
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:
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-----
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
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.
+----------------+
| 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
+----------------+
| 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
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.
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
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.
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
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
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", RFC2622, 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++)", RFC1786,
March 1995.
[3] Villamizar, C., Alaettinoglu, C., Meyer, D. and S. Murphy,
"Routing Policy System Security", RFC2725, June 1999.
[4] Zsako, J., "PGP Authentication for RIPE Database Updates", RFC
2726, December 1999.
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
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 RFCEditor function is currently provided by the
Internet Society.