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

[Russ Housley <[e-mail]>]

Tim:

I think that RFC 6487 should also be updated to adjust the RPKI certificate profile.  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.

Russ

> On Sep 1, 2020, at 4:18 AM, Tim Bruijnzeels <[e-mail]> 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, [e-mail] 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:
>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-deprecate-rsync/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-sidrops-deprecate-rsync-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-deprecate-rsync-00
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> 
>> _______________________________________________
>> Sidrops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops