The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 8 January 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

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

2. 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.¶

3. File Formats

In this synchronization protocol the signal layer makes use of DER-encoded messages [X.690].¶

Design note: DER encoding was selected for its canonical properities and because RPKI cache implementations already support ASN.1 encoding.¶

RpkiErikIndex-2025
  { iso(1) member-body(2) us(840) rsadsi(113549)
    pkcs(1) pkcs9(9) smime(16) mod(0)
    id-mod-rpkiErikIndex-2025(TBD) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
  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) }

ErikIndex ::= SEQUENCE {
  version [0]           INTEGER DEFAULT 0,
  indexScope            IA5String,
  indexTime             GeneralizedTime,
  hashAlg               DigestAlgorithmIdentifier,
  previousIndex         Digest OPTIONAL,
  partitionList         SEQUENCE SIZE (1..ub-Partitions) OF PartitionListEntry }

ub-Partitions INTEGER ::= 1024

PartitionListEntry ::= SEQUENCE {
  partitionIdentifier   INTEGER (1..ub-Partitions),
  hash                  Digest }
END

RpkiErikPartition-2025
  { iso(1) member-body(2) us(840) rsadsi(113549)
    pkcs(1) pkcs9(9) smime(16) mod(0)
    id-mod-rpkiErikPartition-2025(TBD) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
  SubjectInfoAccessSyntax
  FROM PKIX1Explicit88 -- in [RFC5280]
  { iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) }

  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) }

ErikPartition ::= SEQUENCE {
  version [0]           INTEGER DEFAULT 0,
  partitionTime         GeneralizedTime,
  hashAlg               DigestAlgorithmIdentifier,
  manifestList          SEQUENCE SIZE (1..MAX) OF ManifestListEntry }

ManifestListEntry ::= SEQUENCE {
  hash                  Digest,
  manifestNumber        INTEGER (0..MAX),
  location              OCTET STRING } -- subjectInfoAccess extnValue

END

4. Snapshots and Differentials

Clients can 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.¶

Snapshots are encoded using the POSIX [ustar] format and compressed using GZIP ([RFC1951], [RFC1952]).¶

Differences between snapshots will be specified at a later time.¶

Design notes: The ustar format was selected because it is 'streamable', widely available, and an open standard. A compressed form is mandated because opportunistic compression in the transport layer (e.g. HTTP compressed content-encoding) is not universally available. On the flip side, .tar.gz objects likely wont be produced in a deterministic fashion across different implementations, warranting a choice of some other archive format. ¶

5. 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.¶

6. 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 Section 6.6 of [RFC9286]).¶

7. 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. ¶

8. 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.¶

9. Open Questions

This section is to be removed before publishing as an RFC.¶

• 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 Synchronisation?¶

10. 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.¶

11. Security Considerations

This document makes no changes to RPKI certificate validation procedures.¶

See Section 5 of [RFC8182] for applicable security considerations.¶

12. IANA Considerations

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

Decimal  Description                      References
--------------------------------------------------------------
    TDB  id-mod-rpkiErikIndex-2025        [this-draft]
    TDB  id-mod-rpkiErikPartition-2025    [this-draft]

Acknowledgements

The authors wish to thank George Michaelson, Theo de Raadt, Bob Beck, and Theo Buehler 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.¶

Authors' Addresses