Re: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-00.txt

Tim Bruijnzeels <> Fri, 04 September 2020 20:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 877953A0FA5 for <>; Fri, 4 Sep 2020 13:10:26 -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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XGpWk8jWyXNS for <>; Fri, 4 Sep 2020 13:10:24 -0700 (PDT)
Received: from ( [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 631BC3A0D87 for <>; Fri, 4 Sep 2020 13:10:24 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:55e4:165c:ff49:a540] (unknown [IPv6:2001:981:4b52:1:55e4:165c:ff49:a540]) by (Postfix) with ESMTPSA id 9399024533; Fri, 4 Sep 2020 22:10:22 +0200 (CEST)
Authentication-Results:; dmarc=fail (p=none dis=none)
Authentication-Results:; spf=fail
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1599250222; bh=QbEvMKj+LCdJLBe/Fo+4GKgoma89g7mc7wGgMeH4saE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=CC0xc8WBlnR305F7svrRKZFyLbfXc8kboHK5xuyfyQGSERf0uhsWdmtlLW/q6QHKF Q/IRY2ojCP0HnHqc9jPHhd+4FmBHZ4pmliKb83nAHg/B6ajdKXuX2ZD4BFht3punoK bwHlaoc9vcKWxKaCiGQwXPC/nmwphyGGkQyf+heY=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Fri, 04 Sep 2020 22:10:22 +0200
Cc: SIDR Operations WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Russ Housley <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-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, 04 Sep 2020 20:10:27 -0000

Hi Russ,

On 4 Sep 2020, at 17:40, Russ Housley <> wrote:
> Tim:
> I think that RFC 6487 should also be updated to adjust the RPKI certificate profile.

Can you please elaborate why?

My personal drive with this draft, despite its name perhaps, is to deprecate the *operational* dependency on rsync. In my opinion the rsync URIs can stay and serve as namespaces, even if the servers are not guaranteed to be available. Think XML name spaces. I don't think we need to forbid running rsyncd either.

>  In phase 1, several URLs in the certificate could offer rsync:// and rrdp://, and then in Phase 4 (not documented), the rsync:// can get dropped.

It may not be aesthetically pleasing, but removing the rsync URIs completely is a much, much bigger effort. Incomplete dump of pointers of what would be affected:

RFC6487: allow https URIs, or URNs maybe

RFC8183: Repository Response, replace rsync base uri
RFC8181: Publication Protocol, no more rsync uris
RFC8182: RRDP, includes rsync uris - replace

RFC6492: 'up-down': Let CAs request certs with other URI types

New OIDs mean that all RPs treat objects as invalid. Essentially all RPs would have to support the new OIDs before anything can be deployed by CAs - or they will reject all publication points. Child CAs can only deploy when parents support. Extending RFC8181 and 6492 will mean multiple versions.

If we really do need to go down this path, then I believe that this exceeds the possible scope of this single document. And if we do *all* this, then we should probably stop to think first about whether current repository structure, and RRDP (which tried to follow rsync as close as possible) are really what we want then.

So, in short I would then suggest that we do this as a separate effort. And we live with rsync URIs as namespaces for a while. Then at least the operational burdens can be reduced while we figure out how to solve it completely.


> Russ
>> On Sep 1, 2020, at 4:18 AM, Tim Bruijnzeels <> wrote:
>> Hi all,
>> I just submitted this as WG document per request by the chairs on July 16.
>> The issues that I think could be most controversial are:
>> 1) rsync URIs as object identifiers (section 4)
>> In summary: the document proposes that we keep rsync URI as useful object identifiers even if the objects cannot be retrieved at that location. The main reason for this is pragmatism: introducing a new kind of object identifier (e.g. URN based) would introduce a breaking change and make deployment much, much harder.
>> 2) rsync still allowed
>> Currently the document says (tries to say) that if operators want, they can still leave an rsync server running. While they are not required to do so, it is not forbidden either.
>> 3) rsync URIs in RRDP - can they be trusted?
>> Finally, we recently had a discussion related to manifests (6484-bis) and a concern was raised that the rsync URIs in the RRDP XML cannot be trusted. I also took this to the list on 25 June (subject RRDP and rsync URIs). But for clarity I think it's best to continue to discuss here.
>> While it may seem odd that the rsync URIs could be for different hosts than the RRDP base URI, my main original motivation for allowing this in RRDP was to provide CDN support. The Publication Server may outsource its HTTPS function to a CDN, but it may not possible for this CDN to handle or forward rsync requests.
>> While any RRDP server can include any rsync URI in the <publish> and <withdraw> elements in its XML, this is not really an issue because relying parties know both the rsync URI *and* the RRDP server when validating - so they can look for the rsync URI at the relevant RRDP server only.
>> The Publication Server (PS) is supposed to let its publisher publish under a base uri only (RFC8181 and 8183). None of this is changed. In principle the PS can have bugs, or do a poor job of checking this. But they are already able to mess things up when we have rsync only. Because of the compound URI (RRDP + rsync) there is no new attack vector opened this way.
>> Kind regards,
>> Tim
>>> On 31 Aug 2020, at 21:05, 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-deprecate-rsync-00.txt
>>> 	Pages           : 10
>>> 	Date            : 2020-08-31
>>> 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.
>>> In short this plan consists of the following phases.
>>> 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 must no longer be used.
>>> Measurements will need to be done to help determine when it will be
>>> safe to transition to the final phase of this plan.  During this
>>> phase Repositories will no longer be required to provide rsync access
>>> for RPKI validation purposes.  However, they may still provide rsync
>>> access for direct access to files for other purposes, if desired, at
>>> a best effort basis.
>>> 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 separate documents for the plan, and each phase, so that it
>>> might be more clear to all when the updates to RFCs take effect.
>>> 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
> _______________________________________________
> Sidrops mailing list