Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-00.txt

Ties de Kock <> Fri, 26 March 2021 09:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DB963A19EB for <>; Fri, 26 Mar 2021 02:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EbDtG9MReXwR for <>; Fri, 26 Mar 2021 02:43:24 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39C983A19E8 for <>; Fri, 26 Mar 2021 02:43:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version: Content-Type; bh=rEri+F2F2UDIdF7VByKp39gQ7OJQ/8urDNHueb8cOIU=; b=PaVksMUZhbJh 7w67HtctvRpftZoRGS/yVwenQEAg6z9BUe9l/M9Tp2aD5uOXjA4QKG/yLAz1JUFdfReNTU8p7HNNb tDcnWoZ9wZE0X4sOufgY/+kvhI71bczZj9vpRIYLFt+xqbmzZnEJhydt946j8po2nhlV6jfIM+i+N QLmhzCKwh09ig6o33YHdZ2oYu/k7kY88bT84FTs6RfryHAxrvfuA57UxYi+ChEadbPB3tEyzXmWze jmdYAE4jCML7sKFG5xtxDtrmvmnwG7Zw/qiSpCFNaze28V9qtLKjhOk1ntmAQLhhY5PYJz33geUva yI/mFLc0vbasxkruTW0sjg==;
Received: from ([]:41880) by with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <>) id 1lPizt-000BXE-NC; Fri, 26 Mar 2021 10:43:17 +0100
Received: from ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::3aa]) by with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <>) id 1lPizt-0000qO-Ka; Fri, 26 Mar 2021 10:43:17 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Ties de Kock <>
In-Reply-To: <>
Date: Fri, 26 Mar 2021 10:43:15 +0100
Cc: SIDR Operations WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Tim Bruijnzeels <>
X-Mailer: Apple Mail (2.3654.
X-ACL-Warn: Delaying message
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e104277d7bdc6c4aed22c574413cec2985
Archived-At: <>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Mar 2021 09:43:30 -0000

Hi all,

Following a discussion in the chat during the SIDROPS session, I think it is
better to take this to the list.

Currently, RRDP clients could (RRC8182, 3.4.5) fall back to alternative
repository access mechanisms (i.e. rsync) when there were any issues when
retrieving RPKI data from an RRDP repository server.

If this will change into a MUST without considering the timing of the fallback,
this will have an impact on the availability of rsync repositories. Let me build
the case of why RRDP clients falling back to rsync will act as a thundering herd
and will cause fallback to fail, and how we can mitigate that.

We observe that rsync clients update infrequently (~hourly) and RRDP clients
update frequently. The majority of clients in our logs check notification.xml
every 10 minutes. We also see that HTTP failures are temporally correlated,
clients detect a failure (in CDN or backend) at the same time. From this, it
follows that clients will observe a failure at the same time and will fall back
at the same time.

Scaling rsync for the total number of relying party instances, when spread out,
is achievable, even for a large repository. However, scaling rsync so it is
available when all clients fallback in a short period (we see ~1170 unique ips
retrieve notification.xml in a 10 minute window) is difficult.

Fallback will happen rarely, which implies that their copy of the repository is
potentially (very) outdated. A clean copy from rsync takes ~10-15 CPU-seconds
per client (and potentially a large number of IOPS hitting the backing storage)
on the server-side.

That is why I would like the draft to include text that recommends that fallback
is spread out. I would propose that when RRDP is failing (due to content or
connectivity), the clients retry RRDP until a set time at which they fall back
to rsync.

For a repository operator, it is optimal if all clients are spread out over
time. For fallback, this means that a client keeps trying rrdp for a
random delay from the uniform distribution of 0...rsync_update_interval after
the first failure before falling back to rsync.

The alternative is that, when clients act like a thundering herd, the rsync
repositories will not be available for an extended period. If clients retry at a
very similar interval, the repositories will be overloaded for an extended time.

Please let me know what you think of this mechanism,


> On 23 Feb 2021, at 08:44, Tim Bruijnzeels <> wrote:
> Dear working group,
> I have asked for 15 minutes on this subject at the upcoming WG session.
> Differences in this version:
> - rename 'deprecate-rsync' -> 'prefer-rrdp' - as this is the first goal (phases 0-1-2)
> - discuss deprecate rsync as a post-phase-2 goal
> - start discussion of what would be needed to have transport agnostic names (no rsync in uris)
> - moved implementation status overview to the end
> Regards,
> Tim
>> On 23 Feb 2021, at 00:45, wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the SIDR Operations WG of the IETF.
>>       Title           : Resource Public Key Infrastructure (RPKI) Repository Requirements
>>       Authors         : Tim Bruijnzeels
>>                         Randy Bush
>>                         George Michaelson
>> 	Filename        : draft-ietf-sidrops-prefer-rrdp-00.txt
>> 	Pages           : 13
>> 	Date            : 2021-02-22
>> Abstract:
>>  This document formulates a plan of a phased transition to a state
>>  where RPKI repositories and Relying Party software performing RPKI
>>  Validation will use the RPKI Repository Delta Protocol (RRDP)
>>  [RFC8182] as the only mandatory to implement access protocol.
>>  The first objective is to make RRDP the preferred access protocol,
>>  and require rsync as a fallback option only.  This will greatly
>>  reduce the operational burden and concerns for RPKI repository
>>  operators.
>>  In phase 0, today's deployment, RRDP is supported by most, but not
>>  all Repositories, and most but not all RP software.
>>  In the proposed phase 1 RRDP will become mandatory to implement for
>>  Repositories, in addition to rsync.  This phase can start as soon as
>>  this document is published.
>>  Once the proposed updates are implemented by all Repositories phase 2
>>  will start.  In this phase RRDP will become mandatory to implement
>>  for all RP software, and rsync will be required as a fallback option
>>  only.
>>  It should be noted that although this document currently includes
>>  descriptions and updates to RFCs for each of these phases, we may
>>  find that it will be beneficial to have one or more separate
>>  documents for these phases, so that it might be more clear to all
>>  when the updates to RFCs take effect.
>>  Furthermore, this document currently includes an early discussion of
>>  a future objective, which would be to change the RPKI standards such
>>  that names in RPKI objects are no longer tightly coupled to rsync.
>>  By using transport independent names and validation, we will obtain
>>  the agility needed to phase out rsync altogether and/or introduce
>>  other future access protocols.
>> The IETF datatracker status page for this draft is:
>> There are also htmlized versions available at:
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________
>> Sidrops mailing list
> _______________________________________________
> Sidrops mailing list