Routing Policy System Replication
Extracted elements (32)
A lightweight mirror (e.g., a router) needs only to trust its adjacent mirror, check that mirror's signature, and apply changes without any authorization re-check — enabling routers to mirror only the objects needed for route filter configuration with minimal implementation complexity.
No encryption is specified for repository-to-repository authentication because encryption may be illegal in some jurisdictions. Authentication is done via cryptographic signatures (PGP) rather than encrypted channels, satisfying integrity without encryption.
To enable reliable authorization re-verification after loading a snapshot, it is preferable to download an older snapshot (at minimum twice the repository expire time) rather than the most current one, so the replication protocol can fetch subsequent transactions that provide the necessary object version history.
An implementation may allow configurable levels of syntactic conformance with RPSL to enable RPSL extensions to be incrementally deployed across the distributed registry scheme without breaking existing repositories.
The legacy email submission method (RFC-822 encapsulation, optionally PGP-signed) must continue to be supported for backward compatibility with existing RIPE tools; the preferred socket-based submission with transaction-submit-begin/end delimiters is a new addition.
A non-originating repository must redistribute a failed transaction in order not to cause a gap in the sequence, since a transaction only fails to get a sequence number at the originating registry.
A repository must reject a redistributed transaction that does not include any 'repository-signature' meta-object. The originating repository must append exactly one 'repository-signature' meta-object following submitted text and auth-dependency objects.
A repository that receives a 'commit-request' must not redistribute the request, and must delay the response until the corresponding transaction has been processed; it must keep state about pending commit requests.
Each repository that has originated at least one transaction must periodically send a 'heartbeat' meta-object; the interval between two successive heartbeats is configurable but must be less than 1 day.
If not all previous transactions (those with a lower sequence number) from the same repository have been received or completely processed, the repository must 'hold' this transaction until ordering is satisfied.
If this transaction has already been processed or is currently being held, the repository must silently discard this incarnation of the same transaction to prevent duplicate processing.
Transactions must not be encrypted because it may be illegal to use decryption software in some parts of the world. No encryption capability is specified to comply with import, export, and use restrictions.
When authorizing/authenticating a received transaction, the repository must not use an object from a repository not mentioned in an 'auth-dependency' meta-object, and should only use object versions within the transaction sequence numbers of the auth-dependency meta-objects.
When submitting a group of objects to a repository, a user MUST append exactly one 'timestamp' and one or more 'signature' meta-objects, in that order. A repository must reject a transaction that does not include any 'signature' meta-object.
Person and role objects containing contact information should not be redistributed by default due to legal implications in some countries. Fields requiring email addresses must also accept NIC-handles as an alternative to avoid mandatory exposure of contact information.
The 'auth-dependency' meta-object records which external repositories' objects were used for authorization; it carries the repository name, the sequence number, and timestamp known at the originating repository at processing time. Multiple instances are ordered from most to least preferred.
The 'commit-request' and 'commit-response' meta-objects implement an optional two-party commit confirmation protocol. commit-response carries commit-status of 'held', 'error', or 'succeeded'; 'held' is returned when a dependent repository has expired.
The 'delegated' attribute, allowed in any hierarchical RPSL object type (as-block, aut-num, inetnum, route), indicates that further searches in the hierarchy must be made in one or more alternate repositories listed as its value.
The 'heartbeat' meta-object carries the originating repository name, the highest assigned sequence number, and a timestamp. Upon receipt, a repository updates its liveness record and redistributes the heartbeat unmodified to peers.
The 'integrity' attribute may appear in any RPSL object and takes values 'legacy', 'no-auth', 'auth-failed', or 'authorized' (default when absent). Objects with non-'authorized' integrity may be overwritten by any properly authorized addition.
The 'repository' RPSL object identifies a routing registry and carries: query-address, response-auth-type, submit-address, submit-auth-type, repository-cert, expire, and heartbeat-interval as mandatory attributes, plus optional descr, remarks, notify.
The 'repository-signature' meta-object contains the repository name, an optional integrity value (overrides transaction-label integrity if present), and an optional PGP signature covering all text from transaction-label through this object's integrity attribute.
The 'transaction-label' meta-object prepended by the originating repository carries: transaction-label (globally unique DB identifier), sequence (64-bit unsigned integer), timestamp, and optional integrity. It heads every redistributed transaction.
The 'transaction-request' meta-object requests a range of transactions from a peer using optional sequence-begin and sequence-end attributes; after transmitting, the peer must send a 'transaction-response' meta-object echoing the requested range.
An originating repository may replace a clear-text password signature with 'signature: clear-text-passwd <maintainer-name>' to avoid propagating credentials, since clear-text passwords imply full trust to the originating repository and need not be forwarded.
PGP signatures on transactions must cover the original content, not other signatures, so that multiple signatures can be checked in any order. The repository-signature covers from transaction-label through the signature's repository-signature and integrity attributes, but excludes the signature attribute itself.
Signing routing registry objects alone is insufficient for security; authorization checks must be repeated as transactions are flooded because objects used for authorization may change after insertion, making traceback to epoch prohibitively expensive and gameable by exceeding search depth.
Transaction processing on receipt: (1) decapsulate transaction-begin and decode, (2) check for duplicate/held and discard if so, (3) verify originating repository signature, (4) hold if prior sequence numbers are missing, (5) optionally accept trusted-repository integrity mark, (6) verify RPSL syntax, (7) authorize/authenticate or hold awaiting referenced objects.
A database snapshot consists of files X.db (all RPSL objects, blank-line separated, ending with '# eof'), optional X.<class>.db per-class files, and X.transaction-label. Files may be gzip-compressed (.gz suffix) and/or PGP-signed (.sig suffix).
The expire and heartbeat-interval attributes in the repository object use the format 'dddd hh:mm:ss' (days, hours, minutes, seconds). The expire value should be larger than heartbeat-interval.
The 'transaction-begin' meta-object prepends every transmitted transaction and carries the byte length of the transformed redistributed text and an optional transfer-method ('plain' or 'gzip', defaulting to 'plain'). An implementation must support both encoding types.
Timestamps use the format 'YYYYMMDD hh:mm:ss [+/-]xx:yy' where xx:yy are UTC offset hours and minutes. This format is used in the timestamp, heartbeat, auth-dependency, and transaction-label meta-objects.