The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidrops-rpki-erik-protocol-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Job Snijders , Tim Bruijnzeels , Tom Harrison , Wataru Ohgai | ||
| Last updated | 2025-12-02 (Latest revision 2025-12-01) | ||
| Replaces | draft-spaghetti-sidrops-rpki-erik-protocol | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-sidrops-rpki-erik-protocol-01
SIDROPS J. Snijders
Internet-Draft BSD
Intended status: Standards Track T. Bruijnzeels
Expires: 5 June 2026 RIPE NCC
T. Harrison
APNIC
W. Ohgai
JPNIC
2 December 2025
The Erik Synchronization Protocol for use with the Resource Public Key
Infrastructure (RPKI)
draft-ietf-sidrops-rpki-erik-protocol-01
Abstract
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, easy to
implement, and robust in the face of partitions or faults in the
network.
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 5 June 2026.
Snijders, et al. Expires 5 June 2026 [Page 1]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.3. Related Work . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Informal Overview . . . . . . . . . . . . . . . . . . . . . . 5
3. Erik Synchronization Data Structure Definitions . . . . . . . 5
3.1. General Syntax . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. eContentType . . . . . . . . . . . . . . . . . . . . 7
3.1.2. eContent . . . . . . . . . . . . . . . . . . . . . . 7
3.2. ErikIndex . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. The version field . . . . . . . . . . . . . . . . . . 8
3.2.2. The indexScope field . . . . . . . . . . . . . . . . 8
3.2.3. The indexTime field . . . . . . . . . . . . . . . . . 8
3.2.4. The hashAlg field . . . . . . . . . . . . . . . . . . 8
3.2.5. The partitionList field . . . . . . . . . . . . . . . 8
3.3. ErikPartition . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. The version field . . . . . . . . . . . . . . . . . . 9
3.3.2. The partitionTime field . . . . . . . . . . . . . . . 9
3.3.3. The hashAlg field . . . . . . . . . . . . . . . . . . 9
3.3.4. The manifestList field . . . . . . . . . . . . . . . 9
4. Client-side Processing . . . . . . . . . . . . . . . . . . . 10
5. Querying an Erik Relay . . . . . . . . . . . . . . . . . . . 10
5.1. Fetching objects by hash . . . . . . . . . . . . . . . . 11
5.2. Fetching ErikIndex objects . . . . . . . . . . . . . . . 11
6. Transport Error Detection and Handling . . . . . . . . . . . 11
7. Setting Up an Erik Relay . . . . . . . . . . . . . . . . . . 11
8. Comparison with other RPKI transport protocols . . . . . . . 12
8.1. Comparison with Rsync . . . . . . . . . . . . . . . . . . 12
8.2. Comparison with RRDP . . . . . . . . . . . . . . . . . . 12
8.2.1. Garbage Collection . . . . . . . . . . . . . . . . . 13
9. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 13
Snijders, et al. Expires 5 June 2026 [Page 2]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
10. Operational Considerations . . . . . . . . . . . . . . . . . 13
10.1. Scaling considerations . . . . . . . . . . . . . . . . . 13
10.2. HTTP Compression . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12.1. S/MIME Module Identifier . . . . . . . . . . . . . . . . 14
12.2. SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . 15
12.3. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Implementation status . . . . . . . . . . . . . . . 18
Appendix B. Example objects . . . . . . . . . . . . . . . . . . 19
B.1. Example ErikIndex . . . . . . . . . . . . . . . . . . . . 19
B.2. Example ErikPartition . . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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, easy to
implement [RFC1925], and robust in the face of partitions or faults
in the network.
1.1. Background
The notion of cache-to-cache data replication of unvalidated data was
documented in Section 3 of [RFC7115].
| Validated caches may also be created and maintained from other
| validated caches. Network operators SHOULD take maximum advantage
| of this feature to minimize load on the global distributed RPKI
| database. Of course, the recipient relying parties should re-
| validate the data.
|
| -- RFC7115, section 3
Snijders, et al. Expires 5 June 2026 [Page 3]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
Historic records show that experiments have been performed in this
space using, for example, peer-to-peer file sharing technology (see
[P2P]), but no standardised and widely-deployed mechanism for cache-
to-cache replication emerged since then. The authors hope that the
Erik Synchronization protocol might be suitable to fill this gap and
improve propagation speed of validly signed repository data as well
as help reduce load on the global RPKI.
1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.3. Related Work
The reader is assumed to be familiar with the terms and concepts
described in "Maintenance of duplicate databases" [RFC0677], "An
Infrastructure to Support Secure Internet Routing" [RFC6480], "The
RPKI Repository Delta Protocol (RRDP)" [RFC8182], "Manifests for the
Resource Public Key Infrastructure (RPKI)" [RFC9286], "A Digital
Signature Based on a Conventional Encryption Function" [M1987].
1.4. 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.
ErikIndex The relay's Merkle root for a given FQDN. An ErikIndex is
an ordered listing of ErikPartition object hashes.
ErikPartition An ordered listing of the manifest objects' hashes,
manifestNumber values, thisUpdate values, and their certificates'
SIA extension values.
Snijders, et al. Expires 5 June 2026 [Page 4]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
2. Informal Overview
Erik Synchronisation is an architecture to reliably distribute RPKI
repository data from cache to cache using so-called Erik relays.
Relays maintain a validated cache themselves and can be clients of
other relays. While this property suggests that a group of relays
should converge to the exact same state, the distributed nature of
the RPKI prevents relays from achieving strict synchronization.
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 hash of the ErikIndex represents the entire dataset
related to a given FQDN. If the ErikIndex 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, except for
ErikIndex objects, is fetched using static addresses derived from
object hashes. This approach reduces unnecessary data transfer
between caches which contain mostly similar data.
The client starts by querying an Erik relay for the relay's current
ErikIndex for a given FQDN. If the ErikIndex is different compared
to the previous run (or compared to the Index calculated from the
locally cached objects). With the ErikIndex in hand, the client can
determine which ErikPartition are missing and fetch accordingly. The
client then can compare the _manifestNumber_ sequence number and
_thisUpdate_ for each manifest listed in the ErikPartition, and
proceed to fetch (purportedly) newer versions of manifests of
interest. Whenever a relay has manifests with a lower sequence
number on offer, the client can ignore those. The client now has
sufficient information to proceed to fetch any missing Certificates,
Signed objects, and CRLs. With the information contained within
manifests, clients can fetch addressed by content (by hash) and store
by name (or some other scheme).
3. Erik Synchronization Data Structure Definitions
In this synchronization protocol the _signal layer_ makes use of DER-
encoded messages [X.690].
_Design note: DER encoding was selected for its canonical properties
and because RPKI cache implementations already support ASN.1
encoding._
Snijders, et al. Expires 5 June 2026 [Page 5]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
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
-- EXPORTS ALL --
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 PKIX1Implicit-2009 -- in [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) }
;
EncapsulatedContentInfo ::= SEQUENCE {
eContentType CONTENT-TYPE.&id({ContentSet}),
eContent [0] EXPLICIT OCTET STRING
(CONTAINING CONTENT-TYPE.&Type({ContentSet}{@eContentType}))
OPTIONAL }
ContentSet CONTENT-TYPE ::= {
ct-rpkiErikIndex | ct-rpkiErikPartition, ... }
ct-rpkiErikIndex CONTENT-TYPE ::=
{ TYPE ErikIndex IDENTIFIED BY id-ct-rpkiErikIndex }
id-ct-rpkiErikIndex OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) id-smime(16) id-ct(1) erikindex(55) }
ct-rpkiErikPartition CONTENT-TYPE ::=
{ TYPE ErikPartition IDENTIFIED BY id-ct-rpkiErikPartition }
id-ct-rpkiErikPartition OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) id-smime(16) id-ct(1) erikpartition(56) }
ErikIndex ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
indexScope IA5String,
Snijders, et al. Expires 5 June 2026 [Page 6]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
indexTime GeneralizedTime,
hashAlg DigestAlgorithmIdentifier,
partitionList SEQUENCE SIZE (1..ub-Partitions) OF PartitionRef }
ub-Partitions INTEGER ::= 256
PartitionRef ::= SEQUENCE {
hash Digest,
size INTEGER (100..MAX) }
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),
thisUpdate GeneralizedTime,
locations SEQUENCE SIZE (1..MAX) OF AccessDescription }
END
3.1. General Syntax
The content of an Erik object is an instance of
EncapsulatedContentInfo.
3.1.1. eContentType
The eContentType is an OID specifying the type of payload in this
object.
3.1.2. eContent
The eContent is the payload of the Erik object encapsulated in an
OCTET STRING.
3.2. 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.
Snijders, et al. Expires 5 June 2026 [Page 7]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
3.2.1. The version field
The version number of the ErikIndex object MUST be 0.
3.2.2. The indexScope field
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 Section 3.5 of [RFC1034] and modified by
Section 2.1 of [RFC1123].
3.2.3. The indexTime field
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
Section 4.1.2.5.2 of [RFC5280].
_Design note: using the most recent partitionTime, rather than the
local system's notion of "now", helps reduce churn in distributed
systems._
3.2.4. The hashAlg field
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 [RFC7935].
3.2.5. The partitionList field
This field is a sequence of PartitionRef instances. There is one
PartitionRef for each current ErikPartition. Each PartitionRef is a
tuple consisting of 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 hash.
Snijders, et al. Expires 5 June 2026 [Page 8]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
3.3. 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, manifestNumber values, thisUpdate values,
and their end-entity certificates' SIA extension values.
3.3.1. The version field
The version number of the ErikPartition object MUST be 0.
3.3.2. The partitionTime field
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
Section 4.1.2.5.2 of [RFC5280].
_Design note: using the most recent manifest thisUpdate value, rather
than the local system's notion of "now", helps reduce churn in
distributed systems._
3.3.3. The hashAlg field
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 [RFC7935].
3.3.4. The manifestList field
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
Section 4.2.1 of [RFC9286]).
Snijders, et al. Expires 5 June 2026 [Page 9]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
A ManifestRef is a structure consisting of the hash of the manifest
object, the size of the manifest object, the manifest issuer's key
identifier, the manifestNumber, and the thisUpdate 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.
4. Client-side Processing
Clients start by fetching an ErikIndex, which is represents the
relay's current Merkle tree head for a given FQDN. A client MUST
verify the requested FQDN exactly matches the indexScope value in the
ErikIndex, and if not proceed to use a different relay.
Then, clients can decide whether or not to fetch ErikPartition
objects listed on the ErikIndex, for instance, by checking whether
the object associated with the hash was already fetched at some point
in the client's past.
Before using a ErikPartition, the client MUST verify that all URIs in
the accessLocations in the id-ad-signedObject accessMethod instances
in the ErikPartition are encompassed in the requested indexScope. A
client can then decide whether or not to fetch a given manifest
object, by comparing the manifestNumber and thisUpdate 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 one relay or another in order to achieve a
successful fetch. A client MUST verify that the URI in the
accessLocation in one of the id-ad-signedObject accessMethod
instances in the manifest's Subject Information Access (SIA) is
encompassed in the requested indexScope.
As there is no concept of 'sessions' (like in RRDP), clients can
interchangeably use different Erik relays. When one Erik relay
generates a HTTP error, the client can try fetching the requested
object from another Erik relay. To improve reliability, clients
should alternate among different relays in successive query and fetch
attempts.
5. Querying an Erik Relay
Snijders, et al. Expires 5 June 2026 [Page 10]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
5.1. Fetching objects by hash
This specification uses "Named Information" identifiers mapped to
.well-known HTTP/HTTPS URLs for object retrieval, as described in
[RFC6920].
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
5.2. Fetching ErikIndex objects
The URIs to fetch ErikIndex objects can be constructed using the
following Well-Known URI template with the erik keyword as suffix and
the FQDN as parameter: https://{relay_host}/.well-known/erik/
index/{FQDN}.
For example, the URI to fetch an ErikIndex for the rpki.ripe.net FQDN
from a relay at relay.example.net would be:
https://relay.example.net/.well-known/erik/index/rpki.ripe.net.
A client MAY use the If-Modified-Since HTTP header when fetching
ErikIndex objects.
6. Transport Error Detection and Handling
The client MUST calculate the hashes of fetched objects and verify
they are the same as the expected hashes (which are embedded in the
URIs through which the objects were 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]) and try again at a later point in time in a next
validation run.
7. Setting Up an Erik Relay
Erik relays can be operated by any party, without permission from or
coordination with publication point operators or CAs. Relays are
made accessible via either HTTP or HTTPS or both.
Snijders, et al. Expires 5 June 2026 [Page 11]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
Relays generate and make accessible ErikIndexes and ErikPartitions
derived from their current validation state, the client then cherry-
picks which objects (if any) it wishes to fetch. In turn, relays
fetch fresh data from other relays, or from CA-designated publication
points accessible via Rsync ([RFC5781]) and RRDP ([RFC8182]).
_Design notes: a decision must be made on a deterministic "manifest-
to-partition" assignment scheme. Job's proof-of-concept relay (see
Appendix A) uses the first few octets of the the Manifest's AKI as a
stable partition assignment scheme. Other strategies could be to
assign manifests to ErikPartitions based on the "hour-of-day" of the
CMS signing timestamp, or the first few octets of the SHA-256 of the
manifest object._
8. Comparison with other RPKI transport protocols
Ignoring obvious mechanical "on the wire" differences between Erik,
Rsync, and RRDP; there are a number of concept differences between
the protocols. Rsync and RRDP can be described as "general purpose"
synchronisation protocols: they could be used to transfer any
arbitrary set of files, on the other hand the Erik protocol is RPKI-
specific: part of its signaling layer are RPKI manifest objects,
which RPs require as recourse for validation anyway. This property
by itself causes a small deduplication in the data to be transferred.
8.1. 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.
Experimentation suggests that when synchronizing once an hour, Erik
consumes less network traffic than Rsync generally would consume
which, in turn, is less network traffic than RRDP would.
8.2. 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.
Snijders, et al. Expires 5 June 2026 [Page 12]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
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.
Experimentation suggests that when synchronizing every 15 minutes,
Erik consumes less network traffic than RRDP generally would consume
which, in turn, is less network traffic than Rsync would consume.
8.2.1. 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.
9. Open Questions
This section is to be removed before publishing as an RFC.
* Which of the possible deterministic manifest-to-partition
assignment strategies yield the best results? AKI?
* Are deterministic and cheap Snapshots possible? If so, 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 upper bound for the number of partitions? (ub-
Partitions)
10. Operational Considerations
10.1. Scaling 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
Snijders, et al. Expires 5 June 2026 [Page 13]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
requests per second. This order of magnitude in terms of scaling
requirements can easily be handled by a single commodity server.
10.2. HTTP Compression
Using gzip compression on average tends to yield a 20% reduction in
RPKI object size, therefore it is RECOMMENDED for clients and relays
to offer support for compressed content coding, as described in
Section 8.4.1 of [RFC9110].
Using a previous version of a RPKI object as a compression dictionary
for a newer version enables delivery of a delta-compressed version of
the changes, usually resulting in significantly smaller responses
than what can be achieved by compression alone. Clients can
facilitate delta compression by sending an Available-Dictionary
request header, using a previously fetched version of the RPKI object
as the dictionary. It is RECOMMENDED for clients and relays to make
use of Compression Dictionary Transport ([RFC9842]).
11. Security Considerations
This document makes no changes to RPKI certificate validation
procedures.
Paraphrasing Section 11 of [RFC6810]: The RPKI relies on object, not
server or transport, trust. That is, the Regional Internet Registry
root trust anchors are distributed through some out-of-band means,
and can then be used by each relying party to validate certificate
chains and Signed Objects. The inter-cache relationships are based
on this object security model; hence, any cache-to-cache transport is
assumed to be unreliable at times. See Section 5 of [RFC8182] for
more security considerations.
To avoid certain forms of replay attack, clients MUST verify
purported indexScope, ManifestRef location values, and manifest
Subject Information Access (SIA) extensions match the expected FQDN.
Byzantine events or faults in relay-to-client communication can be
overcome by the client rotating requests for objects among different
Erik relays.
12. IANA Considerations
12.1. S/MIME Module Identifier
The IANA is requested to add an item to the "SMI Security for S/MIME
Module Identifier" registry as follows:
Snijders, et al. Expires 5 June 2026 [Page 14]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
Decimal Description References
----------------------------------------------------------
TDB id-mod-rpkiErikSynchronization-2025 [this-draft]
12.2. SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1)
The IANA has allocated for this specification in the "SMI Security
for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry as
follows:
Decimal Description References
----------------------------------------------
55 id-ct-rpkiErikIndex [this-draft]
56 id-ct-rpkiErikPartition [this-draft]
Upon publication of this document, IANA is requested to reference the
RFC publication instead of this draft.
12.3. Well-Known URI
An URI Suffix in the Well-Known URIs registry specific to Erik
synchronization will be requested. See https://github.com/protocol-
registries/well-known-uris/issues/67 for the request.
The proposed suffix is erik.
13. References
13.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/info/rfc1123>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Snijders, et al. Expires 5 June 2026 [Page 15]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810,
DOI 10.17487/RFC6810, January 2013,
<https://www.rfc-editor.org/info/rfc6810>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<https://www.rfc-editor.org/info/rfc6920>.
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for
Algorithms and Key Sizes for Use in the Resource Public
Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
August 2016, <https://www.rfc-editor.org/info/rfc7935>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
<https://www.rfc-editor.org/info/rfc9286>.
[X.690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
February 2021,
<https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
13.2. Informative References
Snijders, et al. Expires 5 June 2026 [Page 16]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
[M1987] Merkle, R., "A Digital Signature Based on a Conventional
Encryption Function", Advances in Cryptology -- CRYPTO '87
Proceedings, Lecture Notes in Computer Science, Vol. 293,
DOI 10.1007/3-540-48184-2_32, 1988,
<https://doi.org/10.1007/3-540-48184-2_32>.
[P2P] Austein, R., Bush, R., Elkins, M., and L. Johansson, "RPKI
Over BitTorrent", March 2012,
<https://www.ietf.org/proceedings/83/slides/slides-83-
sidr-9.pdf>.
[RFC0677] Johnson, P. and R. Thomas, "Maintenance of duplicate
databases", RFC 677, DOI 10.17487/RFC0677, January 1975,
<https://www.rfc-editor.org/info/rfc677>.
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925,
DOI 10.17487/RFC1925, April 1996,
<https://www.rfc-editor.org/info/rfc1925>.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010,
<https://www.rfc-editor.org/info/rfc5781>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC7115] Bush, R., "Origin Validation Operation Based on the
Resource Public Key Infrastructure (RPKI)", BCP 185,
RFC 7115, DOI 10.17487/RFC7115, January 2014,
<https://www.rfc-editor.org/info/rfc7115>.
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017,
<https://www.rfc-editor.org/info/rfc8182>.
[RFC9842] Meenan, P., Ed. and Y. Weiss, Ed., "Compression Dictionary
Transport", RFC 9842, DOI 10.17487/RFC9842, September
2025, <https://www.rfc-editor.org/info/rfc9842>.
[rpkitouch]
Snijders, J., "rpkitouch", December 2025,
<https://www.github.com/job/rpkitouch>.
Snijders, et al. Expires 5 June 2026 [Page 17]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
Appendix A. Implementation status
This section is to be removed before publishing as an RFC.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942.
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
A few experimental Erik relays are available, each running on
slightly different schedules. Client implementers are encouraged to
round-robin between these instances to observe results.
http://relay.rpki-servers.org/ Dublin, Montreal, Osaka, São Paulo,
Sydney - anycasted distributed computing cluster
http://dub.rpki-servers.org/ Dublin, Ireland, - distributed
computing cluster (6 machines, NFS backend)
http://atl.rpki-servers.org/ Atlanta, USA, - distributed computing
cluster (2 machines, NFS backend)
http://miso.sobornost.net/ Amsterdam, NL, single node
http://nyc.rpki-servers.org/ New York, USA, - single node
http://fnllwqoupfrhso6643whm6lpkgsftjtc6crpehmyz2o7pffirnqy7rad.on
ion/ Erik relay service via Tor
An experimental Erik static content generator was developed by Job
Snijders in the form of [rpkitouch] using C.
Snijders, et al. Expires 5 June 2026 [Page 18]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
Appendix B. Example objects
Included in this section are an ErikIndex for rpki.ripe.net and an
ErikPartition referenced from the aforementioned ErikIndex, both
Base64 encoded.
B.1. Example ErikIndex
This object was retrieved from http://miso.sobornost.net/.well-
known/erik/rpki.ripe.net.
MIIoSAYLKoZIhvcNAQkQATeggig3BIIoMzCCKC8WDXJwa2kucmlwZS5uZXQYDzIwMjUxM
jAyMTA0OTQ4WgYJYIZIAWUDBAIBMIIoADAmBCDLPQS+BEMR5/k+VqCStUokMYXOriW2Du
YPTXhGuD3q3wICPZYwJgQgwlY1EG7f5W2l7esjg8zvh4OSH3mEvf0R0Vk0Nu/FNvkCAkW
QMCYEIJ5sldkWmXH8WqdwcqCjWgCAHGO+csZ1Z0M/DLSRlGWbAgI+ZTAmBCDQMhQDUY0A
tI0yab95wpOekpHO0ohKIjYOTTtWQ5MjVwICRl0wJgQgCSczNOep4UZs1zgKjgEUfy4n+
Lt2q/0ae3MXxayJqSACAjzNMCYEICScxxhNA422P1ixrpjqeXBxMu4aaVzsJRswbr/4jp
rrAgJL8TAmBCD89DufanWBskoIDl/9JHi9Si1nlVHpL1voMzTRfVi5tQICQMgwJgQgUQi
roMWezWX3bZfmj6mZ9seGDNoYUSe3TGs8pu0kp1MCAki/MCYEIIC3F0uA3RvYCLXNsnxf
LgfwBadm19t/a+zdn2kAXMgEAgJKWDAmBCA71fzRZoa5ZNS7YZqFu1K/ce5NXUdEwkGSM
7hGlgSS/wICSlkwJgQgLINxwbUPOzmYs57mJRpwL6LRnnhIoAbaKIIj95HG2eMCAjpnMC
YEIPJOBKm1l6lSmeSA08MIQ/F5sKW2em1QlBmS39ZSIUNeAgJHKDAmBCD4ud337DM7zbD
hUyvk+lcH7DM3ZDP+41UXnhSUgYqg/wICOZ0wJgQgk4IS/59oVYy6u2snvNBnjnxJVm/r
eqJJoc1evuvxfHICAkpZMCYEICpdbc0rxiH+33FC3wZV6EuGPjDKy6nYqeDIDA0dRpUpA
gJDKzAmBCBREWPGHXwjb4L5wA4+WfFwpZw5WHYu/esm5gvZqMh/swICPMwwJgQg9RbRtS
WscmO1H+9birDeQPqjjhllFte2FHajdOj1A+cCAkJhMCYEIMCCJYNoCiS3HXHDtq4xGp8
uYDE/xz4bbAO4bwSnnLyEAgJFkTAmBCCEgZwchVDMZS/pzvUkGov3o0+39BkKcJPunwHV
sq476wICQZQwJgQgBGIZWDkNQpZkOa0eD6BSwkvolP/AJw/A311oyvOGEXUCAkP4MCYEI
FOtigW3sRv7apfmjXMU/98TtDj6yMc/RYdpJm0Fd8vbAgIxpDAmBCBhDapgT42X+yfsn9
esviI99SSyYOIP8Rbx9n5G87vNKwICRY8wJgQg1pW35b6HYu+U17pSH5gUt0Osrbz+Tg5
qwNZlezvgZfACAkjBMCYEIEkKKE1Ic+kEV7dH5tnsn6byIHXVRnGY7te0NtXf7qEwAgJP
ITAmBCCxmBlkbyflk0lOVmagNnZKoiZTm4EVQt4iN4J6jBxInwICNmowJgQgkdhrbw7Uz
A8SbEnZNsbEvdkCPxqEEUtiSZSzeRCP0DcCAky7MCYEILO3T1eY7WHJRQmkheD8FtOXlD
5zgH/U2vvWU3S8WnQlAgJOUTAmBCC6RLBWGgEhRVycwJgaUhAGs6SWgkz+Tfn1LADn8qJ
A/AICQ/kwJgQgnstvn8RQM++YOJ+Hc+Tq2VLaID/7jyQRm2nkcWxqcC8CAkskMCYEILT2
DFwyJ43PzJqGR88ETRLfH1W2uhwAJ0DeIHmC2EzPAgJGWTAmBCCYG3Ver1Z0ilotL9Tnz
5MYmCXK2+E6hX8X8wsRB0DZ0QICSYswJgQgRozFaBkI7cN7wmpk5NqiQtG+KC5IIPaUnF
UeQrIb4GkCAkcoMCYEIPBjnA3JhaiTdEW+OIXToWiziXHNmrC1kSnxjkiZ84yyAgJGXTA
mBCAQruf4rgz2DLzWXzUmZkpuaHyGiQcCUR2zAsrBDsyshwICOmYwJgQgUsVU5FeHifx6
XmEcOYlB11aFikVQsRgm/CXu6L7Ri+ACAjpnMCYEIDU3pHZL5KsxrSh+pWu8xz/iU3NeQ
HDD1gaIKLDu71etAgJP6zAmBCByJmxkmOh2xM2iulqF+bgkL7B2GZoBI5tGa4qnQ1Qs6Q
ICPM0wJgQgDAZIYMMIyM7EVTeqHnFehbDl2dfsd2JeSAvze8h1DDsCAkGSMCYEIASg5TH
iOIsCA4TIyvP/3VDYvxa1I7jipkXj+FFufc8nAgJBlTAmBCAJlttvcW33qcB+SE96uC4J
CNtv6YrW7fLwlkND49Ch6gICTyEwJgQgjkPin8Zx3xRQvVTLDI7PiZgvThdVmltUv8pCX
mkDCFwCAjs1MCYEIKqwbw3roJ9qE95izXmO1zDVc9KZb5XdGksdNlv1MwvrAgJXGDAmBC
BYBVT6y9cqNSC+5Gu000vkMpZvvLMgTuzJ/BJMEqgYRQICPKUwJgQgaPL69AnEywa8gW1
DRyIFBiMqKxKvhXExwGwiVYy3ePkCAj2VMCYEIID68c3di63IqfsC6OqD9edaXdzxZDid
pT8vW4DhpMuEAgI6aDAmBCBumuNw5h1oDRKWurgalA9DG/aJvhEZoeAQwg6lRnyG/QICO
Snijders, et al. Expires 5 June 2026 [Page 19]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
AQwJgQgt3xwRTIgnW8O+ULQTPI7z2LDgM03FxfRQ4lHcotEMnICAkMtMCYEIIzRCANsKd
u1W8AOuZ8vWBZs2sJcilWELvU4Kr6v42zdAgJL8TAmBCDDvzk9JcpGPTZbaknn1VgC8sG
i75zjgRa7xAmpDGUSFAICRlswJgQgrDIilsWciW7KPuTh3kkHass55OEFSZLxU8V9Weov
+uECAj5hMCYEIEagNMKITBGhdaxwyQEpG7Hyt/+wZ5vV6lvDHPqJgEFsAgJIvzAmBCANS
W1K5fZD6T2mMPJ34pA5tyIerfepicF4KbR3i/biDAICOmgwJgQg9QTrVWSzgsLTZJ+kfr
2hTwfHwFtyk1MY5eJiQIj64tcCAki/MCYEIEtgvqig8o3dAmn8aP2Fifg59dQ0L/I97is
3IJLFz4ciAgI8zDAmBCBF9ZmDmwaRiOJAcKhszUoPPWBgCSOfwl/7TXxYAy84LgICSlkw
JgQgPSJ4YIZUPV1s+iXFz31lWP58iJBwBfzeSiRhKkDCj1cCAj2ZMCYEIAQZ52tjUKFcd
w6CZL0BatjqxYXeEzgkS0ctra53vpilAgJFkTAmBCBW99Spa4aD/b15yDxn+NrCTd05ZW
fvAEJdJsCSCIzReQICRMQwJgQgkFEctwlUTy0/rLJ9HFlSIfmm4u1SfH5byNxTIdq0ba8
CAkP3MCYEIKEn/SEG+NrbSXVVszg1OUqJhp/7yxQ7XaXqSs5ntoiDAgI/MTAmBCC7UoWk
S9KK+0xMKbMN90X74GTbZ8FGhBmOFgoDJsH5fAICPMowJgQgBeKDMjOj6m0Db6bSBVziu
GQVbX6ggxVhPgUoEAudwmcCAj2YMCYEIPCuJtYZ0XqSCcWlciMZqerJEqQqbwnyPK6Gj5
oSHi3HAgJL8DAmBCC8FPDFwVFa0ue+Ga2qDFPXAxKQoQ5Dx5LViSLA8H+yEwICOAQwJgQ
gxquSz1m2On+sj8U3b4LuFCXYQO3f12OKKAcUrQJJX7ECAkskMCYEIJrIuE8n+2rFZVBT
diS7Fk4EeJRe+xbkrOEt2Ofp90pfAgJIvjAmBCCdViQs6Rl+dDBNZ++ZqQDVnB6QqnZI9
lL8yAby96ZEhQICRZAwJgQgBQBbnKFIiCz6nWT0+dcX7q1kRRU6mQnRQn0Agt46NB4CAk
MrMCYEIMl+Gr2J66EP/KcHkk4IBHYKDj/6U7jDd/1R8PC7LbO1AgJLJTAmBCCdrVc8tfd
LPKyU6B0afSgLQ6gsONsx2PtFEpInwlRsBwICNmwwJgQgmW67+LZvxB0gmoqU7ufdhg2o
Gh1kfUfgDGrePe7/b6ECAkTEMCYEIPEAe2BAUrLpgcI9lsnfEhmd0SipsuJUAUiqBl4gg
+/6AgJAyTAmBCCQ6Ifex5ACWM6v08/ZynSnSOUAXwHGwyDVrfTkhqP9gQICPM0wJgQgfH
LpNTVDUVqb+6e+BAprAtciDp4jsXvoens2CTBKcdACAkWRMCYEIG2MPlfpXo0JVkh1+G2
+VSmRDyYQk9qjLyXhOSubSKlkAgI+ZTAmBCBpgiDKz8VfFYos/EiIcoAea1/s3HVcVQ/0
PpA1Sh0pZAICRY8wJgQgeWF2nZdWGVSLZY7EpUMRlKIJtZ06RQNKGGWicTBnE2UCAk2IM
CYEIGfOKXB2wDjfUf5oImfyVbjZTigjuXZ2XkNT7THpE8x5AgJExDAmBCDr7QYR/atfOe
wk5AqRBdV5n69uE5ioPIWZK5OFoo/qmQICSlgwJgQgumKpDlv4ZzrHr6zkTYAPPGn4kMy
bHxfwRUdi1wew0SACAjzNMCYEIMnx3vC1MilfOgmyMCIx7W3HWpBIDAqC5Zqs8cDubzRu
AgJCXzAmBCCPI9LUV66NK/KxyKnj+iGY2o54zlTB4qFKk627/IuAKQICOmgwJgQgvgpxv
ghCJ9MzM7CNGzCK6jNwcYfGjsHIcJhC43lMNOECAkZdMCYEIK8XFgHZQlrwBGpMLe3+GE
bHDMKHSN5apQ2Pa6UWKZEmAgJTGzAmBCAjXaj7jjiNd9n/vSNc3DXKtsyHgcLpOq8qpV6
z8+3z9gICSYswJgQgA696Menu7atoEjDWjL0ibZB9LM/qqyB+kqumuWV9EagCAkDJMCYE
IG7n4ZVrfuMTOBw1us70bpgZND/EYY8CL6TE5e8l7UiqAgIxpDAmBCCwUKbGCdGF/uSb/
ls9w9j4XsUAcOxXOist/eVbWHoZagICT+owJgQgtVkpLddMj2GaBlldGk06i1D3mcKRmO
Z+a2IlTEXTKOsCAkmLMCYEINF2RK2PNlV8nEYEXmwXHeIJYnAeSLs5/+UtcnNZUUrkAgI
/MDAmBCAdhflZvTg7PLmCfsPihGE9YNeJ96yCuA2xrCgPN7FkdAICQmEwJgQgc5JaLiKE
gMXuaFiL9PEGwnbEfcL/URJmSak5qxg5XQMCAj/9MCYEIM8GaoAYs0BM1AnvqGFR5EYjz
IDZgA3Wq03+d06Q5uGGAgI5nTAmBCDNGx7E/UbPs1Sv08i5j4+f9SIAzaKUMZESELLAms
1XSgICQMkwJgQgopQcABPwDMwkMU0hTfNE1/LEmg3Vaho03WQVoGhrIqICAkf1MCYEIJR
3ccHNn6DmWxTaFiGDM+h6SRQlqufxbAL0EvhZKaYWAgI+ZDAmBCAJDVskResmE6tdqonH
ZkIz9AXQ+AL1+0nufxW/GO0p2wICS/EwJgQg7KZMa4tUPSJj6Tu/U7vG7i4nP6Q52ouvG
2Ip0dEJTM4CAkGVMCYEIB/tw7R9GzpTQm6E61OjM16ScU8AcOiusPkwSKiEQlLKAgJD9j
AmBCCVm/BA+9wO2p5SEULkGYn4B7sJJ9T4qbEiHvPUBNf27QICPmYwJgQgZiRlmPIpTQC
eEJq2pTmOexaVqaf0AzqdyJTGQz7cy0MCAj/8MCYEIBZVXPkjproRqcVwRr+LQe2xKrhi
LyKFvqxcRJq7igciAgI//TAmBCD6pKFc7xD60HVzqgRcFjZhayqk+zBG8h13hwsgR5oTe
AICSyMwJgQgyZjGXGxdkwDSKAe9e6A937+WGD4ogNQ4k2mU8AHOOJgCAkZbMCYEIC2tKP
BNppo/aS3E59VTCQIzOVRbntQ4LIsIQ2J3ZVI3AgJLIzAmBCA1FNkn9bvD45WNH7KH8XZ
gfM6J0IZhim5J6dw3t9I1EQICUYUwJgQgHwCRAkZbYZ5E9gpkp2bDXPpSfbjXLdk3Hb8C
m6LPslICAjTUMCYEII+qKOPkyWJYYPIo92JNI0UkAaR2rDXndvfW6OyBIG4NAgJLIzAmB
Snijders, et al. Expires 5 June 2026 [Page 20]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
CAkJJLvqC9+aQpy1fKaW3ReQmfmcQS/AwX0LEVEpd1ghAICQywwJgQgqYnDAib6Z/3BQf
oyIjwEBZ6qPgm5ugLK6eT+Ob1h3hMCAj8wMCYEIGn1zLGBd5q/n1lNchgV4GkmT5cBiaX
oBoRjGnbIz5SJAgI3ODAmBCD2ev+0Cuv0ftSn8zq3DyaXUC47NyXywwbkKH+XQWPGUQIC
TYcwJgQgbZXv20BACbftVBs0hgSQog0I4j6C5Hrcv8sPVnPCp3YCAky6MCYEIAlp75xUR
Xn+DWf6/GbALvSNBMnWaKD+e5Hg4ne29DjlAgI2azAmBCDjT0ThjwuaSMvENNy6XsVacR
T+eeyTw2QsOI6SCqJ+UQICTLkwJgQglcvBbW/a9mkYDFEQSbNuFz1F1yh3aj/Zd5mALUU
J0CgCAjwBMCYEIEkqxaZ10DA5dcZBYxNkEkePCToSVvK0S5Kxp9XNCQcgAgJNiDAmBCBV
NDuqWcQO7bxRpS9d/pAKCVXh91DsZGGqsyIQWu1ZZgICQMkwJgQgdLbebeGz669U8dE+N
Qey0QK5J0JJTK8e2EuuuCILWs4CAj8xMCYEIDX2V+NkstLIo8dMBgfhzCpAfZvjhMO0UJ
lYLOd9UxmUAgJMvDAmBCA/T4NXC+Zg1FwZliBNAUTEvksubsBj+j3f5h3wLJoUAAICQZQ
wJgQgx5KAKYFvfJ3RrQVCfC3pch9lqWC64JEuUq3miGQkkDsCAkpXMCYEICguELpRR7oz
wvuve35oiG0EvrqEiGory9SdUwosUMauAgJAyDAmBCD9DovOqJG20d1vx8KkSGoOzmcCO
IycrJizGmXd/RTgwQICQZUwJgQgMdZWAbZQVCDxSWnedwXFq++b6pDrVvjyf1wkToSBVN
0CAjwAMCYEIP5zkpkQwRo1FH/fPNmFi87M8mR1vHBSdBNSuB+G6usJAgJEwzAmBCBTGYV
9gClXN0KwEe2fnsXcHODeXeNxkRcW4f7bfyQhSwICQMgwJgQgtt4hiX0Qy/Z8DVemvLOi
DfDXrt2kRDrWRFHFB9aDUgACAi8+MCYEIGDR7kdy6DnyoWs5VLEjkQkzm2IvLisLYGH4r
JgwNvGaAgI4ATAmBCCInuNZlbjqMzpg+ENB8NDx1G/dRncrJ7AnME4Gl8vWPwICOZswJg
Qgm5t1h509U0uQsYdE72F2unnMmBOC5/N54AxD3IIsE+8CAj2ZMCYEIBL4Rp4HzFLsfvS
CsqqqQv8oUjM0056Gkn/cqr1T1sEtAgJL8DAmBCA3VZnxWlrJ8yGDRaxOtnCspwQiDmkN
jyTmKxIJ5V/LOAICQmEwJgQgYTZVzUsoiNGrPReaxUT6ZuShz1efsYswKzeUDYn9qrwCA
kP4MCYEIOZHMCSkKEZQ3cUttoWcEmXz7zBJJ7G27i6NNK6/3SUpAgI/MDAmBCBXH/BGz2
fzMNsDM3XhLrgO/DRhCjVGYPjL/ArDSsF6SwICPy8wJgQghhu6FHXVlsR94hM0+pl+jSa
nJX0JO/MoDUK8heK5cA0CAkP4MCYEIBWkH8qZOZByicQGpnUr91wsNQjly0p2iO9lVH7s
Qgf9AgI/MTAmBCAUc1me7ntJeuvBaQvji9bLo58XlUhza8bkBpz7u/FudwICSyUwJgQgR
6kdpy6OZGlS2luxDS1bpxxTgys8L3L8RI04thJTIFwCAj/9MCYEIDGbZ1cVACFVyHsYxM
F4hkPT7pWLlYvdPD77AE786VXbAgI5mzAmBCAIjmS25AUQD5YUb8+1/tMVr7JCCnfJoEL
ne0gr0C8cNQICR/MwJgQgMgnLU6OuNL/KOsiGtmfer58M6V+a8Y5zUaB7P9xkmXwCAki+
MCYEIJwzgyhH02y3lKF8h2fnvIzx5t4NjdAoc9IJfGcmov30AgJIvzAmBCCcoPOEg0Ohk
nCrTAyLlsNe7v9J1d60SyMd3bnaz6fH/gICOAMwJgQgo0wEjRIkOiE2zduUaCiJ/Ht3hn
GpV3wbcTiGkZUMNIICAjWfMCYEINg1c4AHdYgSVW/GyIbBH3E9HLylQzwHS4smg8oof94
GAgJMvTAmBCBv5H/rhXpFekueNGO+DaZJOlG5eXfOBCnHU+y2Rh3VpQICSL8wJgQgzHjf
JLT7SQR43GiNxIB4rNCQwpQEmd16KEQrayQvOnICAjppMCYEIKZeDtGFQEIG9mSgStoiu
WCObEygoSXkmVK6mMbJ1njKAgI/MDAmBCAacUW8i6aGxqcYL4ZlLb1ZZIkZpBHAqlmW96
ywOqrEdAICRZEwJgQgus/T56q64pop70fUPShKCAZlIIxsSpOXKO4kiRk43a0CAj8xMCY
EICW7MOc1eh3OSW4sziPjxiGwBus7f5h0t9yJ70s8IADJAgI40TAmBCB49B9SCmyQ+EBG
TmUCCp74L0dEs7L9kWNuXr+mM3pkJwICSyAwJgQgT4/8uxHcci0PzHmHXe40FDqnfSnpz
IKNLVmWOr/F5qgCAkjAMCYEIFBHNoHM98kbpQTa8FTRtmclkOL0qlRlnBqX/20L5naaAg
I9lzAmBCBHUSb5G84JCTCvNaBrubbv6q0j1Yk9rdWMbnQN2s9TSgICPZgwJgQgMoRJ6uR
/Vp3cyYQ8CsPKcuNHhvWgc4w5+Joc0Wf9yEUCAkJgMCYEICW5SA3vHsF8/E4bq2L7kQ5i
k2LiWOnf8kO72589QMmfAgJOVDAmBCD0U8quD8lT1jf635qwVir3LPj+RK4NInJaBag/2
dwUSwICRZAwJgQgioix5GFZgsG9q3z1EifwG11F76y4qBXIjea+4SZQPJcCAj5kMCYEIB
VAe13ynujG/+Zz6gHIcyEGi6L8EH9t5edey6K3o83wAgI/+zAmBCBlewO5NxEh59x+vJq
eNWejGYX45xsNXE1UesVD54SdtwICOAQwJgQgH+GokoJV2dLdjv3N6eAejNxGfLP28b2v
valBTVaGKpgCAkP3MCYEILzQABi+ItTcozKEeaflmfCgkIJyB0lhLPbWtJunuUoaAgJL8
TAmBCA1L3QZ/ctkYe7k72yl4hrcMtWcCGTotwP29FbD7aiYdgICRMQwJgQgSPuHGaWVdK
DWfilVP4Gb4I7Apfx7yEpJ66MHQH8mGy8CAj5kMCYEIF4rjGJz1iieFSwTxAnB+yD9nME
bvEpkLupEnHakP7MzAgI+ZTAmBCAHCmdhz9jjnymkzJVMcZYROpptYyX+xftxdQEpxtjC
7wICQMkwJgQgQChJM5OLPC+aFsaqjDn52nssWS7MX8PjP/IM9IlX5Y8CAjzNMCYEIJV2v
Snijders, et al. Expires 5 June 2026 [Page 21]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
MHqDP82+Opv5pA652XNfa+pamj+Z9cG3Uk1Z8fMAgJDKjAmBCBm5FIRsOUYTdMdqzwMc0
PKeOCAydGb9O07a90XcpT7LwICP/0wJgQglJwagCfvu0iaX/dOsG8iPG7ZMot3DzIjflF
hDQFC/VMCAkmLMCYEIM1HAnx6AZowJsatYy3D9AiP0It+hCNjFr6Kny19OYphAgJAyTAm
BCAlabHoS4BSkVBQz1sFMu32KhEjCps9hXPSL81qBSDD3gICRMQwJgQgJo8WXxsumRYWE
Rk97KM/HCb1lvjKCJ9capU2OcoDu9YCAlMcMCYEIM/DwKkhy3H4m+T//BmNHCehY8nA9v
9MFpS8ToXraFbjAgI9mDAmBCA9nS4jENyxBcu0yfoi01mfyXFGmVbKkfwaJBk1fQVcmQI
CSMEwJgQgUy4poeSrFRP/4xid33xZhBVvqkt0Nkyfje1BTafgXpwCAkDIMCYEIMSfAQaf
ygak/g9wl+Fnz5wRwXeuif9QVpMy76BLyvKhAgI8zDAmBCAKmTW2z9LpV14WIRwvu0L7H
Gr3g+jxIZE+EwVczdgSxQICS/EwJgQgJls6yaOcKxeOm4rHGSQqRaqyouAMQLpVGKg8jt
poOJICAky7MCYEIPiMYhaEzQ9hpFKUt9dxwiN6lrsG0chnld0+cz4kkCXYAgI8zDAmBCB
9YDJ4A24F+fUqMdyDUywwhHBf0rr/hnZdyzmNTx+mdAICQl8wJgQgiBzCDLlq2XqoeG+7
5YcnvSc/MzuAvltFmn00QNhEANcCAj8vMCYEIFfdvTpsKEr9AMknFJZSDOgaC/qg+R5w7
MZmOz0G+wgHAgJLIzAmBCAhmdCwm2PFeK9+cTo3hRMWOBdQ7wubLTRzQ2KBEnRy3wICQM
gwJgQgRvD2zanOaAFz5qmQoUFrn0w3x98zg05FXkHCEk0s6ssCAj8xMCYEICNKvRcXjvw
MVSEgYV2TQozroI5YQU6F+RVarK6gRIHsAgJH9TAmBCBlkhKRdMykBXS5AktOWK9kFwtg
KqZ4eXCt/3LFdr+4HwICQMYwJgQgR2H7pi48hwvG6Vaxa7earK7l3qzd0Kftr9n8cBBLB
6MCAj5hMCYEIAEGn9WevNQeGJk0lqiBYGp8FdsS0C4RfrZ5rzW8496lAgJGWjAmBCDHqk
aaxPrEEE7ziSp4KOobiszrN9obQHjGmY/mB9qIcwICQmEwJgQgSG4ckizAIV2HyiUIH2b
AYgD9akr2ffbgyL3wvlzL1isCAlGDMCYEIFIHsiWrb/pl5KBK+8eLbHZaW+mR2DedlySm
/HWU+zY/AgJCYDAmBCCFvlGY8Pkx45g2hMPex5wanXE3xcupWKuWQMUR4KHLMwICOzUwJ
gQgt14YDDtCnxbPTGMOWrsiASCpDSzRu8R9K2m79ztPII4CAj8wMCYEIGIngPL567LeTW
vM4QCvyNr4+1kVVkU9A3ZahQg3tm/QAgJH9DAmBCBE81BID1d1VcGJ6L3kUfU4J004iGa
IWTAYq6enu2cXiwICPZgwJgQgZhjyOe0KsN9FJXC9fhWvgJFlT/ybLQlPM/hkTtsPvI0C
AkWOMCYEIIG/AwfTXiHFYkPx1J7meEAcMN0gti352scmJ4M8WBsFAgI//TAmBCByQvBRt
JUNK63suuV0XBjhWqbmT2ukz8XArV/0oKpT5wICP/0wJgQgCJ1oWH+zFCvk2uuxvSqEN8
gor0zu1tuv4TIQwci1TfQCAkmNMCYEIBQqL+QN2/Mk/l/kHKJDNFq90GurZWwrre3QNKt
FP7i1AgJJjTAmBCDWt0iCseN/ybhYS99r5T0vOCYKSOSf1q8/F5sINOmtAgICNAkwJgQg
s8qn6Xe/OKnjI9ITHnfrc/Yus2/3ixebx/fpEzpnabUCAkf1MCYEIGNeqYuZNidh6wZfP
DGDZivYPQPJaYIEwVPhlVJC1HZWAgJEwzAmBCAeHZ1EX3BbR5CdwrFxQQAs/wrAdx+v1c
wt0szchCg1RQICQywwJgQgffD67rN8L3ILw3a0KmgGVbHJvTb43Iy6c0X0hkf/nB0CAkc
mMCYEIEqa4ij2geU+QQfuEFcRxojmbO6HuIsN45RSv6pCb8XQAgJAyTAmBCAc1Rm3/gOg
JEd01R+tYfs7PRo8zTYroF7Dnl+vq7dqBAICTyEwJgQgnEZv4dk8MEP2jBzDOAtQDjdn8
JYdegubXlK5oNFrxzkCAkMsMCYEILzWd/V6/Kl/5bgKmT3vMGsKHAAZ3Be0pqe5JGf6Pm
hIAgJFkTAmBCBrSAeD/mIL9nUug2pSGQkY/H2Ksfv8l8igTG2jURG+EQICQZUwJgQgv3F
4VnI7R/vTyewzrl3tBu4t+KYhwA9I9lZQICG17vwCAjv/MCYEIOzaLHqLuRi5CAHyT93i
OYgCjc/w02kfoBC3zMZQd5/vAgI9mDAmBCAjAhzfasoBO8TekxFWVaBsTNM57xON+Nn03
C8ug+RNFgICQl4wJgQg4ZkVLSga+phmzGb++WSA7I4kI7p77tHDGxgKrJBjIjACAkMsMC
YEIJ+V96HqzGtmWbgCpN0u3umds3hdNxqJgXzgnLGImORNAgJH8zAmBCBuK5cHy+L9l7N
SM3HZLp66iJMq8zWzOXZwHIwmqoql3gICP/wwJgQgT6GStdV/Gh6jnsy6Z8VNko7LKzTa
BdEjyUnJt5N5i9cCAk/tMCYEIEZLAiFrg8UKxYw6c0HYoftPPEbwKvulprVsIfGoBauyA
gI7MzAmBCBkL/UjTRk6ssWT5GyuF/IBwESy1bF8wDbk7ZBuNzGvOQICSlcwJgQg8MmH2i
2h60fS8crhl+BpykHwOPuECtLdTFWNkO5PNX0CAjWfMCYEIPumvBGRd95pybOOYiUCajl
wr5F4BC+l8vi7Qwm30t2zAgJAxzAmBCAiCFqPM72Yu1JyXQZm7/JCiKA+ABoOq4Vy0vrK
9NiXlwICR/QwJgQgEDS/zNykfeldHIRjFlbSv/vQENImU746xGwE0+FEWh4CAk8gMCYEI
IcWwmcymTwLrGV61QwPPKj6bmTwbo1PpGgBBax7d0BVAgI/LzAmBCCa+Ib1IcQ3HxhVNO
8CbEYH8A6cBh3rZgo1WRU15bTW5QICP/0wJgQgJgN+bz4Y0Tdnzx85kj0LH7tvlGRpy4x
ItxuBma2uDZYCAj/8MCYEIA7+I1vMO4ZkoI4PkJIxPajKbvq1RHhhAtBVWQ+jSz8jAgI9
mDAmBCAKHZqmHuvUNTjVKKyF/6KCeXJYfVbwwZatxqiirySWjQICQ/gwJgQgCVJpXR6EE
Snijders, et al. Expires 5 June 2026 [Page 22]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
/cLCrY/dxjl31tAgSfd99c85iBAT9qHL3wCAk7dMCYEINKcNGpfUzhHE6e9FNViLij+pa
N0NBkc3wFeVc5z3fPKAgJCYTAmBCB999DeJhZ/jh25jyfT7BaXu8z9x2Y7ZL45w5aveCf
XzwICONAwJgQgQ6ePpqQM3J/tAWJNRDVE+zwB6Gq6V9/rFPjRjnThqr4CAjc5MCYEIMw0
LxAX97O+HokACVnfRItxQD5tBlWDdTiuq+mlq3bYAgI4pDAmBCDVIrIsPDyNl4SmB82F6
0uQUh57qUTnlU6V3spkvm2CeQICPmMwJgQg8KC7wuciQ4D/m0XEGKMWijhMlO3+ei29SJ
1V2tJ0y1wCAkDHMCYEIG+IWuA4NGyjFmlYOvNqzEjcrruBEzFNNI6DiQhIWspDAgJCYDA
mBCDxylx/b/WSaYilR7IZ0vQ1woUY9UUKntZY4uNaIluUkAICPZgwJgQgS+M7K6tuebac
VxFjX1DFet5nMfv2b+CqPzksp9jG1rQCAjjRMCYEIIZLqVrG5MlUrIUEYGVpml0m2tDSQ
qawo4W0FTopXtoxAgI8zDAmBCB+EkohX4QKN6YwqvF4ATN1zF2R6iDhhrBEeoJKse3zGg
ICOZ0wJgQgzfBErimweC0BtIKQiMpcuQoftSHe10oYJW6Tm3JiazACAjgFMCYEIKbo/K2
jeb/5vj6f2alhOHCdH1qEsTAgolSnDRi034kiAgJAyDAmBCAWxL531lZDXoxwixMRpbZ8
1MVJMM8Vcg0q7Ps5jjPSIQICP/swJgQgXR6DxJycXEuGwdsnjGEuubANEJbdDc2n/roP9
V1+JTQCAjpoMCYEIL+P2i+gcHBt8UW7/kXh4jiQF91hPoVAhkblnvkKbNJiAgI/fjAmBC
Bkt3eqIMLPhKo2jYgJ8wefmzDS5nNzsGZh1cWfaLcs4gICNeQwJgQgQ1aPgjz3HjRbjkA
mhF7PmIzFD+ad3wC3b281PvzoLT8CAkOAMCYEIOg7kghxKqfHlBeiil8xXgMGSWcFg1XW
CyoF7f9lYFT0AgJASzAmBCBm5L2At89Js1RA6PPD3fxIoCXPcEC3iS2J3ZagaPs1OgICR
Y4wJgQgsiapUbHJXC77xeNTpbGJIhA8brJPJsg1U45j8NNApoICAjc3MCYEID4T1N6vnr
wctWDGvGUb0sKYM5VCRrRx2lHR22St2VapAgI+YjAmBCCZMsTFB07NQg5WSQ9wK8Up8Sp
iapWo1TnICYqfLYlAXwICRMQ=
B.2. Example ErikPartition
This object was retrieved from http://miso.sobornost.net/.well-
known/ni/sha-256/tt4hiX0Qy_Z8DVemvLOiDfDXrt2kRDrWRFHFB9aDUgA.
MIIvOgYLKoZIhvcNAQkQATiggi8pBIIvJTCCLyEYDzIwMjUxMjAyMTAwMTQzWgYJYIZIA
WUDBAIBMIIvATCByQQgAMX+7iIIqxeNVkiTc4Ii2ZeOPl8Rl7vxWNXZ/Q+Ff9kCAggYBB
R/8bgc/mq7EY6X4DJbZi6vmE8vagICDcIYDzIwMjUxMjAyMDMwMTE3WjB2MHQGCCsGAQU
FBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC83NS8xODZhMTgtNWQ3
Zi00M2VkLWIwNmEtY2VhN2ViMzUwNTM3LzEvZl9HNEhQNXF1eEdPbC1BeVcyWXVyNWhQT
DJvLm1mdDCByQQgBG6CUhPUabKPjnLg9qh7lZtS60gM8tjCgWkIWl5AMVICAgfOBBR/yV
alK3NQSk8f80VHGZKXp/XenQICCwoYDzIwMjUxMjAyMDgwMTMwWjB2MHQGCCsGAQUFBzA
LhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9hYS83MWFiNjktNjk2NS00
YjcwLTk2OGQtYmI1N2E0ZWY3MTUzLzEvZjhsV3BTdHpVRXBQSF9ORlJ4bVNsNmYxM3AwL
m1mdDCByQQgCDh5YK7waRs7uM3lMJ7vLIA4w4WYfuAx7+PBQ0ecCcoCAgfOBBR//IJYXf
abfJSxamGTL/yLbjNRVgICEy4YDzIwMjUxMjAyMDcwMzA0WjB2MHQGCCsGAQUFBzALhmh
ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9lNC81MzFkMmItZTE3MC00OWE1
LTg0MDQtOTJmNzNmNTZmYzYyLzEvZl95Q1dGMzJtM3lVc1dwaGt5XzhpMjR6VVZZLm1md
DCByQQgCuO3xDB6RqovsRJRjfibhDYcNEcUtqqAWtszXxK6zUUCAgfOBBR/HVjWLd1+R6
8hlv11S7P/JnmJKgICF1QYDzIwMjUxMjAyMDcwMjUwWjB2MHQGCCsGAQUFBzALhmhycGt
pLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC80Ni8yOTBhNjAtNzkyZi00NDc1LWE5
ZjQtZTNiOWUwYmFlNmFiLzEvZngxWTFpM2Rma2V2SVpiOWRVdXpfeVo1aVNvLm1mdDCBy
QQgDPy278mvBB/Ad+R7gB9u6BCoXVxKglAPftFt+Hic168CAgfOBBR/1i5CwI4WAcRXHg
2Io0mgUJ3qXgICEt4YDzIwMjUxMjAyMDMwMTA2WjB2MHQGCCsGAQUFBzALhmhycGtpLnJ
pcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC83OC9iOTM0ZWUtYzRiYS00MzkxLTgwYjAt
ZTc1YTVlYTg5ZmQxLzEvZjlZdVFzQ09GZ0hFVng0TmlLTkpvRkNkNmw0Lm1mdDCByQQgD
8LuWSLexcmNKKD6MS1emGR3lMlPttDxWq8DU61EzZECAgfOBBR/7j84IHPyw+T8z/yjhM
WwzYJsJgICAycYDzIwMjUxMjAyMDUwMTAyWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGU
Snijders, et al. Expires 5 June 2026 [Page 23]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
ubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9hNy84Y2NlYmYtZjlmYS00YzQ2LWFlZTgtY2Ni
ZmE3MzQyNGE3LzEvZi00X09DQno4c1BrX01fOG80VEZzTTJDYkNZLm1mdDCByQQgEZtfE
5VMnpFveqR56eAGpgGjQdDqghADYYfCZEDblIYCAgfOBBR/+wEVxKzd0bStxAc3gHJqz8
Aa+QICDGAYDzIwMjUxMjAyMDkwMTMzWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV
0L3JlcG9zaXRvcnkvREVGQVVMVC82MS81MjY4ZmMtY2ZlZS00YWE4LTk3YmYtY2JlMDIw
NjY1ZWZlLzEvZl9zQkZjU3MzZEcwcmNRSE40Qnlhc19BR3ZrLm1mdDCByQQgF/Vd2aD0K
oOkqhBrD8ZnsmD9wpVMor+/Dc/Ng+h6NN8CAgqPBBR/a9GmsEYlxXHYMPh4scAjgkdAjA
ICBfsYDzIwMjUxMjAyMDkwMTMzWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3J
lcG9zaXRvcnkvREVGQVVMVC80OC9iYzY2ZDctNTdhYi00NzVkLTk2YmEtODliNmMzMjMx
NWMyLzEvZjJ2UnByQkdKY1Z4MkRENGVMSEFJNEpIUUl3Lm1mdDCByQQgIZBP41uwLyfqJ
yMStBiVsyOdBIKdVOUvnvxRsDs9yHsCAgfOBBR/kt92EPBI9Dv0TDNtQcbBFX7w4gICFu
kYDzIwMjUxMjAyMDIwMTA1WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9
zaXRvcnkvREVGQVVMVC8xNy81OGJlMTgtMmYzNS00YzZhLWFhNmEtN2Y3MmY0NGI4OTgy
LzEvZjVMZmRoRHdTUFE3OUV3emJVSEd3UlYtOE9JLm1mdDCByQQgJMbj6N3sZETMeSxxm
xgcMTCtQdd3WkskVtzzgQ0nfCMCAgfOBBR/5osSI0vXA0MBvJaxOKrid4YKPgICBcIYDz
IwMjUxMjAyMDYwMDU5WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXR
vcnkvREVGQVVMVC84Yi80YTExMTEtOGYzYy00ZWRmLWI3N2MtMmZhMjYzMWJjMzFjLzEv
Zi1hTEVpTkwxd05EQWJ5V3NUaXE0bmVHQ2o0Lm1mdDCByAQgJ9MKT5HNNxRaHePV8odvL
EkLusUbGYiIZOEEMgwddnkCAgfNBBR/MSsJ0faQ8lcAvV3PB8kYDF6WYwIBfxgPMjAyNT
EyMDIwNTAwNTNaMHYwdAYIKwYBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9
ERUZBVUxUL2JjLzI5ZGFjOS05YTE1LTQ2NjEtYWY3OC0xNTIyZTI5NjRmY2UvMS9mekVy
Q2RIMmtQSlhBTDFkendmSkdBeGVsbU0ubWZ0MIHJBCAoLWmQKZmBpUUFVPsy7MnU21sKo
DdeXKXgthCvY5eXDAICCBgEFH8WgCjsDatmimfVv29TWMqr4zeoAgILxRgPMjAyNTEyMD
IwMzAwNTdaMHYwdAYIKwYBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZ
BVUxUL2NjL2IxNTI4Ni1mZDRkLTQ5ZmUtYTY5ZS03ZmFkZjUwYTJlMzcvMS9meGFBS093
TnEyYUtaOVdfYjFOWXlxdmpONmcubWZ0MIHJBCAqkkSMUp64n/LjY9EkJcPzsfhP+AYMS
NcuvRqiEAatDQICB84EFH9C0nwh2obH6fv0SuDlbJjz0vgLAgIO9BgPMjAyNTEyMDIwNz
AxNTNaMHYwdAYIKwYBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUx
UL2E5Lzk4YjAyNC05ZDhmLTQ4NjktYTJhOS0wYWZiN2MzZmJmMzAvMS9mMExTZkNIYWhz
ZnAtX1JLNE9Wc21QUFMtQXMubWZ0MIHJBCAxvg2dc4tSHXnXSH98bnAN5Z5QI1bL2wPfY
wPxnY5jYgICB4QEFH8HV8MxmB4EK3RxNzUn0PZKE1a0AgIS+hgPMjAyNTEyMDIwNzAyMz
ZaMHYwdAYIKwYBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzc
4LzRmOTZmOS01NjlmLTQzM2MtYjlhOC02YTI2MTJkNDBmNTAvMS9md2RYd3pHWUhnUXJk
SEUzTlNmUTlrb1RWclEubWZ0MIHJBCBHafQUxF3NA6JUdDgiSC70WRe/dWegE3gl9ScEJ
XNBLQICB4QEFH8UzoEDt4XzUEvEsy8fTJtwzj9/AgIQExgPMjAyNTEyMDIwNzAyNDBaMH
YwdAYIKwYBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL2I2L2Y
2OWRiZS1lMDc1LTQ0MzgtYjUzYi1mNjE2MGZhMWZiMDIvMS9meFRPZ1FPM2hmTlFTOFN6
THg5TW0zRE9QMzgubWZ0MIHJBCBMXnhom4Q63Nb1rZ8HxdMTILHHfBqyzb6ZsYsOE3c0Q
QICB84EFH9YvAhkEvTSxU+gcC2SziVJbOR5AgIUzxgPMjAyNTEyMDIwMzAxMTVaMHYwdA
YIKwYBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL2NjLzUzMDk
zMy01OTE1LTRmZjItYjFmOS01MDEwZDA1Zjk5YTgvMS9mMWk4Q0dRUzlOTEZUNkJ3TFpM
T0pVbHM1SGsubWZ0MIHJBCBVoKCYkcR6TZPnwUOJSheDpJeCBPoNggLGJBXo2RLlagICB
84EFH8km5VEYgaD+Us4inVRpopkk+0SAgIDhhgPMjAyNTEyMDIwNDAxNDJaMHYwdAYIKw
YBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzhiLzdhYTA0ZS0
0ODA3LTQ5ODgtOTEwMy04NDIzOTdlMzA2NDMvMS9meVNibFVSaUJvUDVTemlLZFZHbWlt
U1Q3UkkubWZ0MIHJBCBa9ki/mAoG9Kp9PlJCfKUt1zVeXLxBcagsdgiFWR6x1gICB4QEF
H9R3x306IZ+QeXn+S3n+dH6DBVNAgIMPBgPMjAyNTEyMDIwOTAxNTVaMHYwdAYIKwYBBQ
UHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL2ZhLzVlNzMxZi01Mjh
Snijders, et al. Expires 5 June 2026 [Page 24]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
iLTRlMDItYWQ2OC02ZDkwMzVhZjE1MzUvMS9mMUhmSGZUb2huNUI1ZWY1TGVmNTBmb01G
VTAubWZ0MIHJBCBcx9Q+329FqMvH7W3YJZEcYgT1x6dycJKWN4NKALbs5AICB84EFH+oF
qMzjTJ0HNT/+PSd2yzIOP3FAgIExxgPMjAyNTEyMDIwODAxMzNaMHYwdAYIKwYBBQUHMA
uGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzUzL2E0NTI4YS05MGU2LTR
kOTEtYTUyYy1mMDcxN2VhNDg1YzYvMS9mNmdXb3pPTk1uUWMxUF80OUozYkxNZzRfY1Uu
bWZ0MIHJBCBjkxk8YV5Ap12jk7mtGtaL50jbsxZ14vP55xR8k7n+7gICCBgEFH/g51k1T
oPMGTIDgRCd4i2g8acAAgIXXBgPMjAyNTEyMDIwNDAxMDVaMHYwdAYIKwYBBQUHMAuGaH
Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzRjLzBjNzI0My0xZmZiLTQ5ZDI
tYjVjMS1iNDAyZThhMWQ5MzQvMS9mLURuV1RWT2c4d1pNZ09CRUozaUxhRHhwd0EubWZ0
MIHIBCBrOdTt95AUso/5Cc59i8OxF/vRYkGC0X2AnFNU6JrXtwICB4MEFH83coPXwjWpP
ce9K4MXsnSPKF/3AgFIGA8yMDI1MTIwMjA4MDExN1owdjB0BggrBgEFBQcwC4ZocnBraS
5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFRkFVTFQvOTIvMGZhZGZjLWY0OWItNDNlOC1iNjI
xLTgzMWUyOTQ0ZjhmYS8xL2Z6ZHlnOWZDTmFrOXg3MHJneGV5ZEk4b1hfYy5tZnQwgcgE
IHCg18vDg8nOH0Imktf6/dShb7OzmCXQcHjpTUUndYB6AgIHzQQUf7UOfTt/0olM+3Dkl
GCLMgzCFcECAWsYDzIwMjUxMjAyMDUwMTE3WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcG
UubmV0L3JlcG9zaXRvcnkvREVGQVVMVC85Ni9hOTE4Y2ItMjA0NC00ZjFjLTk3MDAtOTM
2MDFhMzRmNjJmLzEvZjdVT2ZUdF8wb2xNLTNEa2xHQ0xNZ3pDRmNFLm1mdDCByQQgg3B2
jopDFhv5lafmlABTEXT3PdDmycUF0vvVv4qsm48CAgfOBBR/hemQNUOX42wMqQOgxiDHc
J79zQICA4UYDzIwMjUxMjAyMDkwMDUwWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubm
V0L3JlcG9zaXRvcnkvREVGQVVMVC81ZS80YWUxNzUtNTVkMC00ODRkLThkMTEtOGM5ZDU
4MjNiYWQ5LzEvZjRYcGtEVkRsLU5zREtrRG9NWWd4M0NlX2MwLm1mdDCByQQgh/LB2/IW
n5WpvgaEitBCvTJiIvxsqYuCCw9TwetLEIUCAgilBBR/ytid8b+Zo28pDMPvDx57TQJ1M
wICFzIYDzIwMjUxMjAyMDIwMTE5WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3
JlcG9zaXRvcnkvREVGQVVMVC81NS85ZjhiMTYtMjg0Zi00NTEyLWIzZGMtMDE1ZDlmMWI
0YjUwLzEvZjhyWW5mR19tYU52S1F6RDd3OGVlMDBDZFRNLm1mdDCByQQgiTSCNydCsyhC
BravLWid2StVCdr22al/Txn7WYytr/sCAgfOBBR/USKDdHQt9USqkwWMWjvT0WQhmQICD
scYDzIwMjUxMjAyMDgwMTA4WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG
9zaXRvcnkvREVGQVVMVC8wYS85Mzg1YWEtMWI3OS00YTAyLWEwOTItMDFlYjAzNjg0ZjA
5LzEvZjFFaWczUjBMZlZFcXBNRmpGbzcwOUZrSVprLm1mdDCByQQgiyd2cr50asT5E+FU
NZ9DjcRJf3pHTAz95YHtdMi5DCYCAghgBBR/K6ht94eIj2+FkqgGpv/qMEbAegICF1oYD
zIwMjUxMjAyMDIwMDQ4WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaX
RvcnkvREVGQVVMVC82MC81ZTY3ODYtNjM3Ny00MjI0LWJhMDYtZGM0NzY5ZWZmMWY1LzE
vZnl1b2JmZUhpSTl2aFpLb0JxYl82akJHd0hvLm1mdDCByQQgi/dW04+DLp3y4iuTHFPh
j/3BX08nco/eS6+SHJ90UhYCAgfOBBR/M/xA0uAzO7x73qsr2FmVQwHA8QICBqAYDzIwM
jUxMjAyMDgwMTA0WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcn
kvREVGQVVMVC9iNC82NWJmMWQtZWMxZC00MGU2LTg0OWQtNzk3OTBkNjZkN2QzLzEvZnp
QOFFOTGdNenU4ZTk2cks5aFpsVU1Cd1BFLm1mdDCByQQgjjrmZwAwYmO/XutpgFS0pvq5
QMhKV6OTKQvKyhvTjqsCAghfBBR/UAd9LdimehrotqvWu7NIkCiluwICF10YDzIwMjUxM
jAyMDQwMTM4WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvRE
VGQVVMVC81Yy9jMWMxY2UtZWE1OS00ZGNmLWJjY2MtM2U3Y2FkZDg4YzcwLzEvZjFBSGZ
TM1lwbm9hNkxhcjFydXpTSkFvcGJzLm1mdDCByQQgl4ztfWjMtuBGsCMqqkuxgOjZblNP
eMjdPs33YQUyMjQCAgfOBBR/m0z9ybDZ48MeDruB5vGxy73J5AICDTYYDzIwMjUxMjAyM
DUwMTM2WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQV
VMVC81Yi84MjQ2ZWItODQ2OS00MmRmLWEwOGYtOTBjNDIxZjU1YWRiLzEvZjV0TV9jbXc
yZVBESGc2N2dlYnhzY3U5eWVRLm1mdDCByQQgmNJYdWjP733EBq/xGMRqAp/gY9LnHDad
7m80HqWA/JkCAgfOBBR/7+vRX7xlFIesr2dCT0eD1D60IAICF1IYDzIwMjUxMjAyMDYwM
DUyWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC
85YS8yNmVmNjMtYjcyZi00YjNjLThkZmMtMmJjODQ1MTkyMjdhLzEvZi1fcjBWLThaUlN
Snijders, et al. Expires 5 June 2026 [Page 25]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
Icks5blFrOUhnOVEtdENBLm1mdDCByQQgmf2cQA1kGrnfMdRK1Koho+7W4tb/MHBvZN5N
79kZDpYCAgfOBBR/GIratbVSCB7KyCHJsJA5SHOzFQICEcYYDzIwMjUxMjAyMDQwMTU2W
jB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC85MC
9hNjU1MjItZjdjNS00ODdiLWI3YjgtMmU0NjE0MTQxYWE0LzEvZnhpSzJyVzFVZ2dleXN
naHliQ1FPVWh6c3hVLm1mdDCByQQgnX4AuwUIq4FJ3l8BlaqYALo6B1lge5GaMpP0IHzk
N7ICAgfOBBR/HQ4ymL7Tp/Ofs7JE7ZGL9sTXvwICFSwYDzIwMjUxMjAyMDIwMDUxWjB2M
HQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9mNy9lNj
UwNmUtNzY4NS00OGU3LWE1ODMtMjFhZjNkZWU4ZWU5LzEvZngwT01waS0wNmZ6bjdPeVJ
PMlJpX2JFMTc4Lm1mdDCByQQgnnFg3v7hRWsuutSKC2INQPtmzp51AjNERmUHmoCZysMC
AgfOBBR/Q52UJCb8ZzsnnMmKs1/b1+qX9QICEu4YDzIwMjUxMjAyMDIwMTMzWjB2MHQGC
CsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8yYS82OWEwOW
YtNTgwOS00NjU2LWIzNTUtMTQ2ZjI1NGFjMTMxLzEvZjBPZGxDUW1fR2M3SjV6SmlyTmY
yOWZxbF9VLm1mdDCByQQgo2KuxR/yaVX9kbBmOWrM9IuOj/OFzh+WdnrubtXzD50CAgfO
BBR/902r1OsaoRRxROFbAmaemC/eTQICBwIYDzIwMjUxMjAyMDgwMTM0WjB2MHQGCCsGA
QUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC83ZC8wZmJiZjUtYz
gzZC00Yjk3LTljZWEtMDU1YzQ5YWM2ODI4LzEvZl9kTnE5VHJHcUVVY1VUaFd3Sm1ucGd
2M2swLm1mdDCByQQgpb4yUfq+e3Kb+SPcaxTW3wnwczVSZyeJi+hWEqAPOhQCAgfOBBR/
EUFq45Kd83v2akWc06ymOJHpRgICF1IYDzIwMjUxMjAyMDMwMTMyWjB2MHQGCCsGAQUFB
zALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8yZi82YjIyZTgtM2RjZC
00NGRkLTk1MTQtNjc1NmY3YjBjMGRiLzEvZnhGQmF1T1NuZk43OW1wRm5OT3NwamlSNlV
ZLm1mdDCByQQgraMaZyixFyPaeEX9BytWmTMWCApJR3jyqT2KBAAPsTcCAgeEBBR/KWZX
r40Awl/XX1bsyKKLNRUFdQICEIwYDzIwMjUxMjAyMTAwMDUwWjB2MHQGCCsGAQUFBzALh
mhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9kMC9lODBiMzMtM2JlZS00Nm
VjLWIzNWQtYmFmOTVhNTA2ZDE5LzEvZnlsbVY2LU5BTUpmMTE5VzdNaWlpelVWQlhVLm1
mdDCByQQgthWUYRf3Ko4EDRFnDpxIwSWg/NrI3yUIjKlwU5BLpPICAgfOBBR/49Y7SltA
S1/4PL8rFSWjBHf2XAICBJgYDzIwMjUxMjAyMDkwMDU3WjB2MHQGCCsGAQUFBzALhmhyc
GtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9mNi84MWE2NzItZmU5OC00ZDNmLT
liODMtMmNiN2EzYjZlNDJmLzEvZi1QV08wcGJRRXRmLUR5X0t4VWxvd1IzOWx3Lm1mdDC
ByQQgttAYBOj1CvqqXCRlvKYvnkRKJvkeu17lTnZ1uvrsQNMCAgilBBR/PgsnuOTXmPkr
neFX8dpaQ81J5QICEZMYDzIwMjUxMjAyMDUwMTI3WjB2MHQGCCsGAQUFBzALhmhycGtpL
nJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC81Zi9hMGM5YWMtM2E0Ny00ZDZjLWFhMT
UtYTQyZWM4Nzc2ZmJiLzEvZno0TEo3amsxNWo1SzUzaFZfSGFXa1BOU2VVLm1mdDCByQQ
gt2qjoeqXioD1axDs6VbSwWBexTd9dSFuvNYOwhe3JvsCAgfOBBR/F4+vZAHi83FuMXZF
ad9zHfWPIgICEcoYDzIwMjUxMjAyMDkwMTI1WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpc
GUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC82Ni8xYjc5NjgtY2E0ZC00NWY0LWI2NzEtMm
U3Zjc4NDg5Y2QzLzEvZnhlUHIyUUI0dk54YmpGMlJXbmZjeDMxanlJLm1mdDCByQQguh2
qFxQSPsbZLwh4b8ErTSkC6ghcVw9rEzfnKxbQCoYCAgeEBBR/c2uIoCQE1DBL3a1f9VBK
aDPntwICF1MYDzIwMjUxMjAyMDcwMDU5WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUub
mV0L3JlcG9zaXRvcnkvREVGQVVMVC85OS8wZjI1Y2UtYjk3Ny00ODUzLTllYzMtOWU1Nm
NiNTRmZWY3LzEvZjNOcmlLQWtCTlF3UzkydFhfVlFTbWd6NTdjLm1mdDCByQQgwE4bjYQ
oN32V63OzjC/yXNs7paWki0kXw36lIuOc+g8CAgeEBBR/F7b5MjmdWFCT0YczlOv+Gyn5
jAICDtcYDzIwMjUxMjAyMDQwMTM0WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L
3JlcG9zaXRvcnkvREVGQVVMVC8zMS9jYzAyMDAtYmIyYy00NWY2LWFjNzUtODI3NTc3ZG
Y4ZWRjLzEvZnhlMi1USTVuVmhRazlHSE01VHJfaHNwLVl3Lm1mdDCByQQgxRmFCzil0Q6
95LB2b9TNATvFoS66n9hVIdaw4zsL6ccCAghfBBR/VvKJSMgy8tQ0u0TV3g6hImAbBQIC
F1cYDzIwMjUxMjAyMDcwMjEzWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3Jlc
G9zaXRvcnkvREVGQVVMVC8zYS8yMWZiY2EtODBlMC00YjhjLTg2MjItNGU4NmFkNjRmNz
c0LzEvZjFieWlVaklNdkxVTkx0RTFkNE9vU0pnR3dVLm1mdDCByQQgxYali50YrOH/GXe
Snijders, et al. Expires 5 June 2026 [Page 26]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
0+ytDfMDd8wTOFa8xYbUrKuG5P4sCAgeEBBR/SuV+5uCpxRAfwUqHpTNBULurRgICBqUY
DzIwMjUxMjAyMDIwMTE2WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9za
XRvcnkvREVGQVVMVC8yYi8xMWZhNDQtODg3OS00ZDE5LWI0NjgtNWI1ZDk4ZjUzNjFlLz
EvZjBybGZ1YmdxY1VRSDhGS2g2VXpRVkM3cTBZLm1mdDCByQQgyXd1nRRvk6rtEdWX/rm
J2iyj7r86rfNSnJ1UnIS8YyICAgfOBBR/tD3iN/0LaihziSMJIdJaLC7RqAICFugYDzIw
MjUxMjAyMDUwMTI0WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvc
nkvREVGQVVMVC8wOS9kNGQxMmEtYWI0ZS00ZGJhLTk1ZGUtYmM2MzcxMzBkZTZlLzEvZj
dROTRqZjlDMm9vYzRrakNTSFNXaXd1MGFnLm1mdDCByQQgyaagRnEcy8cfA9Gycczrwed
Mb9AXeaEFBEYipCTRFnYCAgfOBBR/MTYP/Br9Xx2mbYFATkZjUS1JZwICFN8YDzIwMjUx
MjAyMDUwMTI1WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvR
EVGQVVMVC8yZC9mZWY1ZGQtMzhlZS00YmM1LTgyZmYtNTg0ZDc4YTI1ZjhjLzEvZnpFMk
Rfd2FfVjhkcG0yQlFFNUdZMUV0U1djLm1mdDCByQQgzCDlP8WVMADx2mHkfcEMYBAv2xX
5nxxCKq3jGqqnQqkCAgfOBBR/dzTf6hIGV0EuqGfdvHuE0TK/eAICEAQYDzIwMjUxMjAy
MDcwMjE2WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQ
VVMVC83ZS82ODAzMjQtZWUxZi00MGYyLTg4ZGYtMTk2OTMxOTYyZDNjLzEvZjNjMDMtb1
NCbGRCTHFobjNieDdoTkV5djNnLm1mdDCByQQgzf5YvEOPZX+mp3dluVc0p6gck4cqBkM
jM9mp6pdKk50CAgfOBBR/8XrlR7nyZB5gV3/lU92290mghwICBJUYDzIwMjUxMjAyMDUw
MTAxWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMV
C9hNS8xYmMwZjktYmQ3Yy00ZjdhLWE0MDQtYTQzZmYyNWQ0NDdkLzEvZl9GNjVVZTU4bV
FlWUZkXzVWUGR0dmRKb0ljLm1mdDCByQQg2WWHA7kZ1lFtufHhoKOWQJnNNOqe1dZiREa
kbo6PnDQCAgfOBBR/TVkcI60saUd9f3odTOjrzulZbAICBbAYDzIwMjUxMjAyMDUwMDUx
WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8zZ
S8wZDY3YTItYmMzNi00YjkzLWI2MDQtZDRmNWM5MmQ5MDk1LzEvZjAxWkhDT3RMR2xIZl
g5NkhVem82ODdwV1d3Lm1mdDCByQQg2wZZFXRyyeT6Hr9UPTqG+kndFcQa7iQ8lvSNn2t
w1EYCAggYBBR/A6H4wzT9v0t43vDFkv8EkN30sAICFw4YDzIwMjUxMjAyMDMwMTEzWjB2
MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC82Ni8zZ
mUxYTAtYzZmZC00YmM0LWFhZTEtOWVlMDA2OTQyYjRiLzEvZndPaC1NTTBfYjlMZU43d3
haTF9CSkRkOUxBLm1mdDCByQQg5bw010O3isxfFbAcf68+pxZ5hotesydvvAjQWM0t5EE
CAgfOBBR/Pgh0ie4jqUJNU/rCFu5LjgEoDgICFukYDzIwMjUxMjAyMDIwMTExWjB2MHQG
CCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9jNi9jMmM5O
WQtY2Y5MS00ZGZiLTk0ZGUtYTdjNjNkNTYyZTU2LzEvZno0SWRJbnVJNmxDVFZQNndoYn
VTNDRCS0E0Lm1mdDCByQQg52O9fl2mAURiPvp/D/Lxg/qD94CMaHg1gP34sh6wpiACAgf
OBBR/NdWuQX9F7oUF12zqobNMRYOUoAICEDEYDzIwMjUxMjAyMDcwMjE3WjB2MHQGCCsG
AQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9lNi9jNTQ2N2ItM
zk2Mi00Yjc0LWFlMGQtMzQ0NzNiYzkxZDgwLzEvZnpYVnJrRl9SZTZGQmRkczZxR3pURV
dEbEtBLm1mdDCByQQg6so+VkKUIuwqe5qDv/wZ5Mt2jbINjE8muOBTc6lTIkACAgfOBBR
/ao5dVcJJioJjb5n4/J4xngd3HgICEFgYDzIwMjUxMjAyMTAwMTQzWjB2MHQGCCsGAQUF
BzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC83NC8yN2ZjZTEtMTFjZ
S00YTMyLWE2NDktZTA3NmI1MTcyMWFkLzEvZjJxT1hWWENTWXFDWTItWi1QeWVNWjRIZH
g0Lm1mdDCByQQg7uUYDdaLWVx3C5NJxoSM8VliwnFEyUkZN8jWlrPCKDcCAgeEBBR/mRj
KtvHzXvG15YPLKDnpt0ixWAICFCsYDzIwMjUxMjAyMDcwMjU4WjB2MHQGCCsGAQUFBzAL
hmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8yNi9kZjgyZmEtMTE4ZC00M
jE5LWJhMTYtMWE5NjgzYzlkNmNiLzEvZjVrWXlyYng4MTd4dGVXRHl5ZzU2YmRJc1ZnLm
1mdDCByQQg7yfMJqn5pi7RM/A+RAbW8DpFIvpu6jcm+KCoB1tbaHkCAgeEBBR/iyGDWJg
6fXolOKnam6HzSU1xqwICAXwYDzIwMjUxMjAyMDQwMTU1WjB2MHQGCCsGAQUFBzALhmhy
cGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9kOS83NmNkMDMtZWFhMi00OTY1L
Tk0ZWYtOThkYmI2NDAyY2RkLzEvZjRzaGcxaVlPbjE2SlRpcDJwdWg4MGxOY2FzLm1mdD
CByQQg76JcDN7fp3hgATQ70hlg9N95dWMEMjDUwl4LVJXyeJQCAgeEBBR/fl69b6RpxeN
Snijders, et al. Expires 5 June 2026 [Page 27]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
wv8EGxNSq0eHblAICD78YDzIwMjUxMjAyMDkwMDUxWjB2MHQGCCsGAQUFBzALhmhycGtp
LnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8yMy9jM2U4ZWQtNTk3YS00ODVhLTk0Y
TMtOTgyY2ZiMzU5YWVlLzEvZjM1ZXZXLWthY1hqY0xfQkJzVFVxdEhoMjVRLm1mdDCByQ
Qg8nARwXE9Yjvm1l2w8HIxTfh+ukj7kz6ZWpLDErCzzcMCAgfOBBR/KjK6QhloDc3Vj2E
B5ceuwVQKcwICF1cYDzIwMjUxMjAyMDcwMTQ3WjB2MHQGCCsGAQUFBzALhmhycGtpLnJp
cGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC81NS8xNDNlOWUtOTZlNi00NzRlLWFkMmMtM
jJlNmRmNDU4NGFmLzEvZnlveXVrSVphQTNOMVk5aEFlWEhyc0ZVQ25NLm1mdDCByQQg9a
VdJNGRAi9S4ulD3UwiO5jZP+rvST2Rgy2AlEYwXwICAgilBBR/UV6tCV7tmsTKvFq0rQt
YZ9nwGwICF2wYDzIwMjUxMjAyMDkwMTA3WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUu
bmV0L3JlcG9zaXRvcnkvREVGQVVMVC9hNy81YzJhNTktNjAyNS00MDBlLWFiMjgtZjBhN
jI0ZDQwOTEyLzEvZjFGZXJRbGU3WnJFeXJ4YXRLMExXR2ZaOEJzLm1mdDCByQQg+OfbRJ
5zLGiJD6PTAGFKK4J4ynf+/NV2x1xibYY3d20CAgfOBBR/0YpqSZEMwzHckRFK5ZtxhdX
zDQICF1cYDzIwMjUxMjAyMDcwMTAzWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0
L3JlcG9zaXRvcnkvREVGQVVMVC9iYS8wOTQ3ZjItMjJjYS00N2NiLTg5YWQtM2U1MGE1Z
jAxOTk4LzEvZjlHS2FrbVJETU14M0pFUlN1V2JjWVhWOHcwLm1mdDCByQQg/WXtWO4Uk0
axqFIkXli0D/e08zs5A0d2bWZbmwgnrJsCAgfOBBR/VoneSnznaL86tdn4VG6FbMsZNgI
CF1YYDzIwMjUxMjAyMDMwMTA1WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3Jl
cG9zaXRvcnkvREVGQVVMVC83Ny82NGQ1MDUtMjIwNC00ZGNhLWE5NWUtOGI1MzcyNTg0Y
WNkLzEvZjFhSjNrcDg1MmlfT3JYWi1GUnVoV3pMR1RZLm1mdA==
Acknowledgements
The authors wish to thank George Michaelson, Theo de Raadt, Bob Beck,
Theo Buehler, and William McCall for the lovely conversations that
led to this proposal. The authors wish to thank Sean Turner and Russ
Housley for their review of the ASN.1 notation.
This protocol is named after Erik Bais, who passed away in 2024, as a
small token of appreciation for his friendship.
Authors' Addresses
Job Snijders
BSD Software Development
Amsterdam
The Netherlands
Email: job@bsd.nl
URI: https://www.bsd.nl/
Tim Bruijnzeels
RIPE NCC
The Netherlands
Email: tim@ripe.net
Snijders, et al. Expires 5 June 2026 [Page 28]
Internet-Draft Erik Synchronization Protocol for RPKI December 2025
Tom Harrison
APNIC
Australia
Email: tomh@apnic.net
Wataru Ohgai
JPNIC
Japan
Email: alt@nic.ad.jp
Snijders, et al. Expires 5 June 2026 [Page 29]