The Netherlands job@sobornost.net

RIPE NCC

The Netherlands tim@ripe.net

APNIC

AU tomh@apnic.net

JPNIC

JP alt@nic.ad.jp

Operations and Management Area (OPS) SIDROPS Data synchronization This document specifies the Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI). Erik Synchronization can be characterized as a data replication system using Merkle trees, a content-addressable naming scheme, concurrency control using monotonically increasing sequence numbers, and HTTP transport. Relying Parties can combine information retrieved via Erik Synchronization with other RPKI transport protocols. The protocol's design is intended to be efficient, fast, and easy to implement.

Introduction This document specifies the Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI) . Erik Synchronization can be characterized as a data replication system using Merkle Trees , a content-addressable naming scheme , concurrency control using monotonically increasing sequence numbers , and HTTP transport . Relying Parties can combine information retrieved via Erik Synchronization with other RPKI transport protocols ( and ). The protocol's design is intended to be efficient, fast, and easy to implement .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Related Work The reader is assumed to be familiar with the terms and concepts described in "" , "" , "" , "" , and "" .

Glossary This section describes the terminology and abbreviations used in this document. Though the definitions might not be clear on a first read, later on the terms will be introduce with more detail.

Erik relay

An intermediate between CA publication repositories and Relying Parties.

FQDN

The fully qualified domain name of a RPKI repository instance referenced in an end-entity certificate's Subject Information Access (SIA) extension's id-ad-signedObject accessDescription.

Hash

A message digest calculated for an object using the SHA-256 algorithm.

Tree head

Also known as "root hash", this is the hash of the current ErikIndex associated with a given FQDN.

ErikIndex

An ordered listing of Partition identifiers and associated ErikPartition objects' hashes.

ErikPartition

An ordered listing of the manifest objects' hashes, manifestNumbers, and their certificates' SIA extension values.

Snapshot

A compressed tarball archive containing all RPKI objects for a given FQDN.

Informal Overview In this synchronization protocol Merkle trees are used to determine whether differences exist between client and relay. Merkle trees are hierarchical data structures: the hash value of each node is computed recursively by hashing the concatenated hash values of the node's children. The tree head hash represents the entire dataset. If the tree head hash is not the same between two replicas, the relay provides the client with hashes of smaller and smaller portions of the to-be-replicated dataset until the exact list of out-of-sync or missing objects is identified. Sequence numbers are then used to determine whether these differences are relevant enough for the client to fetch. All data is fetched using addresses derived from hashes (except for the hash tree heads). This approach reduces unnecessary data transfer between caches which contain mostly similar data. The client starts by querying an Erik relay for its current tree head for a given FQDN. If the tree head is different compared to the previous run (or compared to the tree head calculated from the locally cached objects), the client can fetch the ErikIndex object using the tree head hash. With the ErikIndex in hand, the client can determine which ErikParitions changed or are missing and fetch accordingly. The client then can compare the manifestNumber sequence number for each manifest listed in the ErikPartition, and proceed to fetch (purportedly) newer versions of manifests of interest. Whenever a relay offers a manifest with a lower sequence number the client can ignore it. With the information contained within manifests, clients can fetch addressed by content and store by name. The client now has sufficient information to proceed to fetch any missing Certificates, Signed objects, and CRLs.

Erik Synchronization Data Structure Definitions In this synchronization protocol the signal layer makes use of DER-encoded messages . Design note: DER encoding was selected for its canonical properities and because RPKI cache implementations already support ASN.1 encoding. RpkiErikSynchronization-2025 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) mod(0) id-mod-rpkiErikSynchronization-2025(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS CONTENT-TYPE, Digest, DigestAlgorithmIdentifier FROM CryptographicMessageSyntax-2010 -- in [RFC6268] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } AccessDescription, KeyIdentifier FROM PKIX1Implicit88 -- in [RFC5280] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) } ; ct-rpkiErikIndex CONTENT-TYPE ::= { TYPE ErikIndex IDENTIFIED BY id-ct-rpkiErikIndex } id-ct-rpkiErikIndex OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) snijders(41948) erikindex(826) } ErikIndex ::= SEQUENCE { version [0] INTEGER DEFAULT 0, indexScope IA5String, indexTime GeneralizedTime, hashAlg DigestAlgorithmIdentifier, partitionList SEQUENCE SIZE (1..ub-Partitions) OF PartitionRef } ub-Partitions INTEGER ::= 1024 PartitionRef ::= SEQUENCE { identifier INTEGER (1..ub-Partitions), hash Digest, size INTEGER (100..MAX) } ct-rpkiErikPartition CONTENT-TYPE ::= { TYPE ErikPartition IDENTIFIED BY id-ct-rpkiErikPartition } id-ct-rpkiErikPartition OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) snijders(41948) erikpartition(827) } ErikPartition ::= SEQUENCE { version [0] INTEGER DEFAULT 0, partitionTime GeneralizedTime, hashAlg DigestAlgorithmIdentifier, manifestList SEQUENCE SIZE (1..MAX) OF ManifestRef } ManifestRef ::= SEQUENCE { hash Digest, size INTEGER (1000..MAX), aki KeyIdentifier, manifestNumber INTEGER (0..MAX), location SEQUENCE SIZE (1..MAX) OF AccessDescription } END

ErikIndex An ErikIndex represents all current manifest objects available under a given FQDN and thus the complete state of the repository as it is known to the relay.

The version number of the ErikIndex object MUST be 0.

The indexScope field contains the fully qualified domain name of the Signed Object location of the manifests referenced through this particular ErikIndex. The FQDN MUST be in the "preferred name syntax", as specified by and modified by .

The indexTime is the most recent partitionTime value among the ErikPartitions referenced from this ErikIndex. The field's value roughly indicates when the ErikIndex was generated and can be used for troubleshooting and measurement purposes. For the purposes of this profile, GeneralizedTime values MUST be expressed UTC (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds. See . Design note: using the most recent partitionTime, rather than the local system's notion of "now", helps reduce churn in distributed systems.

This field contains the OID of the hash algorithm used to hash the ErikPartitions. The hash algorithm used MUST conform to the RPKI Algorithms and Key Size Profile specification .

This field is a sequence of PartitionRef instances. There is one PartitionRef for each current ErikPartition. Each PartitionRef is a 3-tuple consisting of the partition identifier, the hash of the partition object, and the size of the partition object. Information elements are unique with respect to one another and sorted in ascending order of the partition identifier.

ErikPartition An ErikPartition represents a subset of manifest objects available under a given FQDN. Each ErikPartition is an ordered listing of the manifest objects' hashes, manifestNumbers, and their end-entity certificates' SIA extension values.

The version number of the ErikPartition object MUST be 0.

The partitionTime is the most recent thisUpdate value among the manifests contained within this ErikPartition. The field's value roughly indicates when the ErikPartition was generated and can be used for troubleshooting and measurement purposes. For the purposes of this profile, GeneralizedTime values MUST be expressed UTC (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds. See . Design note: using the most recent manifest thisUpdate value, rather than the local system's notion of "now", helps reduce churn in distributed systems.

This field contains the OID of the hash algorithm used to hash the manifest objects referenced in this ErikPartition. The hash algorithm used MUST conform to the RPKI Algorithms and Key Size Profile specification .

This field is a sequence of ManifestRef instances. There is one ManifestRef for each current manifest. A manifest is nominally current until the time specified in nextUpdate or until a manifest is issued with a greater manifestNumber, whichever comes first (see ). A ManifestRef is a 4-tuple consisting of the hash of the manifest object, the size of the manifest object, the manifest issuer's key identifier, the manifestNumber contained within the object, and a sequence of AccessDescription instances from the manifest's End-Entity certificate's Subject Information Access extension. Information elements are unique with respect to one another and sorted in ascending order of the hash.

Snapshots and Differentials Clients should be able to bootstrap initial state by fetching a snapshot. A snapshot contains all RPKI objects a relay associated with a given FQDN as of the time of the snapshot's production. Snapshots do not contain ErikIndex or ErikPartition objects. Because snapshots are not produced in lockstep with updates to the merkle trees, clients MUST perform a tree comparison after fetching a snapshot. Note: Snapshots encoding is TBD. A compressed form (, ) should be used because opportunistic compression in the transport layer (e.g. HTTP compressed content-encoding) is not universally available. Fetching differences between snapshots ('deltas') might be specified at a later time, or might be concluded to be unnecessary. Design notes: While the format is 'streamable', widely available, and an open standard, a notable downside is that .tar.gz objects likely wont be produced in a deterministic fashion across different implementations, warranting a choice for a bespoke format.

Client-side Processing A client can decide whether or not to fetch ErikIndex and ErikPartition objects, by comparing the hash to previous fetches. A client can decide whether or not to fetch a given manifest object, by comparing the manifestNumber with what's locally cached and what's offered by the remote relay. A client can compute which products listed in the manifest's fileList need to be fetched from the relay. As there is no concept of 'sessions' (like in RRDP), clients can interchangably use different Erik relay. When one Erik relay generates a HTTP error, the client can try fetching the requested object from another Erik relay.

Querying an Erik Relay

This specification uses "Named Information" identifiers mapped to .well-known HTTP/HTTPS URLs for object retrieval, as described in . For example, issuance #54 of ripe-ncc-ta.mft has the following SHA256 digest: c2d0427bc5a32c42eea1ab5663d592b1fc29c7d4ef16ab0b5e1d631d039dcc21. To fetch the aforementioned object from an relay hosted at relay.example.net, a client would access the following HTTP URL: https://relay.example.net/.well-known/ni/sha-256/wtBCe8WjLELuoatWY9WSsfwpx9TvFqsLXh1jHQOdzCE

The URIs to fetch ErikIndex objects can be constructed using the following Well-Known URI template with the erik keyword as suffix and the IndexScope as parameter: https://{relay_host}/.well-known/erik/{indexScope}. For example, the URI to fetch an ErikIndex for the rpki.ripe.net indexScope from a relay at relay.example.net would be: https://relay.example.net/.well-known/erik/rpki.ripe.net.

Transport Error Detection and Handling The client MUST calculate the hash of fetched objects and verify it is the same as the expected hash (which is embedded in the name through which the object was retrieved). If there is a hash mismatch, the client may try fetching the object from a different Erik relay or treat this as a failed fetch (see ).

Setting Up an Erik Relay Erik relays can be operated by third parties, without permission from or coordination with publication point operators or CAs. Relays generate ErikIndexes and ErikPartitions derived from their current validation state, the client then cherry-picks which objects (if any) it wishes to fetch. Relays fetch fresh data from other relays or from CA-designated publication points. Design notes: a decision must be made a deterministic "manifest-to-partition" assignment scheme. Job's proof-of-concept relay uses the first few octets of the SHA-256 hash of the manifest for produce as a stable assignment strategy. Other strategies could be to assign manifests to ErikPartitions based on the "hour-of-day" of the CMS signing timestamp or the Authority Key Identifier.

Comparison with other RPKI transport protocols Ignoring obvious "on the wire format" differences between Erik, Rsync, and RRDP; there are a number of key design differences between the protocols. Rsync and RRDP can be described as "general purpose" synchronisation protocols, while the Erik protocol design is RPKI-specific. In the Erik protocol, manifest objects (which RPs require for validation anyway) are an integral part of the signaling layer.

Comparison with Rsync In Rsync, the server and the client construct and transfer a full listing of all available objects, and then transfer objects as necessary. In effect, this allows clients to 'jump' to the latest repository state, regardless of the state of the local cache. A major downside of Rsync is that the list of files itself can become a burden to transfer. As of June 2025, in order to merely establish whether a client is synchronized or not with the RIPE NCC repository at rpki.ripe.net, as much as 5.8 megabytes of data are exchanged without exchanging any RPKI data. When synchronizing once an hour, Rsync generally consumes less network traffic than RRDP.

Comparison with RRDP The key concept in RRDP is that the client downloads a "journal", containing all add/update/delete operations and replays this journal to arrive at the current repository state. A major downside of RRDP is that (depending on the RRDP polling interval) clients end up downloading data which has become outdated. Imagine a hypothetical CA which issues and revokes a ROA every 10 minutes and a client that synchronizes every 60 minutes; in effect the client must fetch 5 outdated states, wasting bandwidth. When synchronizing every 15 minutes, RRDP generally consumes less network traffic than Rsync.

Garbage Collection In contrast to RRDP, the Erik protocol has no concept of server-specific "stateful" sessions that persist across polling attempts. This obviates the need for withdraw instructions as part of the protocol exchange: clients can simply delete objects that are no longer referenced from their current validation state and refetch them later on if needed.

Open Questions

• Should the hash tree heads contain a previous hash field so clients can observe gaps in chains?
• Should ErikPartitions also list the filesize of the referenced manifests? Perhaps there are optimisations possible when the filesizes are communicated to clients?
• Which of the possible deterministic manifest-to-partition assignment strategies yield the best results?
• What is the best archive format for Snapshots? The ustar/gzip combo might not easily yield deterministic results across different implementations.
• Is the concept of Differentials/Deltas needed in Erik Synchronization?
• What will be the upperbound for the number of partitions? (ub-Partitions)

Operational Considerations As of July 2025, the global Internet's RPKI churn rate appears to be 2 new objects per second. The ecosystem is estimated to be composed of ~ 5000 RPKI cache instances and ~ 50 repository servers. Assuming 10 minute fetching intervals and 150 metadata requests per synchronization run (for exchange of Merkle tree data), an Erik relay serving all the Internet's RPKI cache instances would probably need to be able to sustain serving an average of at least 11,000 HTTP requests per second. This order of magnitude in terms of scaling requirements can easily be handled by a single commodity server.

Security Considerations This document makes no changes to RPKI certificate validation procedures. See for applicable security considerations.

IANA Considerations

The IANA is requested to add an item to the "SMI Security for S/MIME Module Identifier" registry as follows:

For the current proof-of-concept phase the id-ct-rpkiErikIndex and id-ct-rpkiErikPartition OIDs were assigned from a PEN arc. This section will be updated once it is clear which IANA-managed registries would be best suited for OID assignment for these object identifiers.

An URI Suffix in the Well-Known URIs registry specific to Erik synchronization will be requested. The proposed suffix is erik.

References Normative References This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols. This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486. ITU-T Informative References Advances in Cryptology -- CRYPTO '87 Proceedings Lecture Notes in Computer Science, Vol. 293 IEEE/Open Group This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document specifies the rsync Uniform Resource Identifier (URI) scheme. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files.

Acknowledgements The authors wish to thank , , , and for the lovely conversations that led to this proposal. This protocol is named after Erik Bais, who passed away in 2024, as a small token of appreciation for his friendship.