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

Tim Bruijnzeels <> Tue, 01 September 2020 08:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C2B93A0D9D for <>; Tue, 1 Sep 2020 01:18:36 -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 3JrPYEGM83sy for <>; Tue, 1 Sep 2020 01:18:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B20C63A0D9C for <>; Tue, 1 Sep 2020 01:18:34 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 8F0851F79C; Tue, 1 Sep 2020 10:18:31 +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=1598948311; bh=iJMPizyN/iMRS4EfnuzfdlyIkS3JW92mNzWmYfA6fxM=; h=Subject:From:In-Reply-To:Date:References:To; b=yh37lGls8ANo/u1s0RLl9NN47omWJKFWtVcbFDoMwV6nADfK7qTxjEhOZ82WW8uss lrvqqIOWZeU4BYyJMIP4Lyq/pYGy6XROJjxB2hPHcvHSz4DUD3aea5ywapsUbSV8kD 5i+Q09IyvHj2odRk0p9W07j5j447VWDVmbcjEltQ=
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: Tue, 01 Sep 2020 10:18:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: SIDR Operations WG <>
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: Tue, 01 Sep 2020 08:18:37 -0000

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,

> 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