Resource Public Key Infrastructure (RPKI) Repository Requirements
draft-sidrops-bruijnzeels-deprecate-rsync-00

Abstract

This document updates the profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository [RFC6481] by describing how the RPKI Repository Delta Protocol (RRDP) [RFC8182] can be used, and stipulating that repositories which are made available over RRDP are no longer required to be available over rsync.

The Profile for X.509 PKIX Resource Certificates [RFC6487] uses rsync URIs in the Authority Information Access, Subject Information Access, and CRL Distribution Points extensions. This document leaves this unchanged, meaning that rsync URIs are still used for naming and finding objects in the RPKI. However, it is no longer guaranteed that objects can be retrieved using these URIs.

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 May 7, 2020.

Copyright Notice

Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Requirements notation
• 2. Motivation
• 3. Rsync URIs as object identifiers
• 4. Updates to RFC6481
• 5. Deployment Considerations
• 5.1. RRDP support in RPKI Repositories
• 5.2. RRDP support in Relying Party software
• 6. IANA Considerations
• 7. Security Considerations
• 8. Acknowledgements
• 9. Normative References
• Author's Address

1. Requirements notation

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.

2. Motivation

The Resource Public Key Infrastructure (RPKI) [RFC6480] as originally defined uses rsync as its distribution protocol, as outlined in [RFC6481]. Later, the RPKI Repository Delta Protocol (RRDP) [RFC8182] was designed to provide an alternative. In order to facilitate incremental deployment RRDP has been deployed as an additional optional protocol, while rsync was still mandatory to implement.

RPKI Repository operators are still required to provide 24/7 up-time to their rsync infrastructure, as long as the requirement to support rsync stands. Thus, the benefit that they get from supporting RRDP, which enables the use of content delivery networks (CDNs) for this purpose, is limited.

And as long as not all RPKI Repositories support RRDP, Relying Party software is still required to support rsync. Because there is a lack of rsync client libraries, this is typically implemented by calling a system installed rsync binary. This is inefficient, and has issues with regards to versioning of the rsync binary, as well as reporting errors reliably.

This document requires that all RPKI repositories and all Relying Parties support RRDP. It also stipulates that these parties are no longer required to support rsync. This way all parties are freed of direct operational dependencies on rsync.

3. Rsync URIs as object identifiers

[RFC6481] defines a profile for the Resource Certificate Repository Structure. In this profile objects are identified through rsync URIs. E.g. a CA certificate has an Subject Information Access descriptor which uses an rsync URI to identify its manifest [RFC6486]. The manifest enumerates the relative names and hashes, for all objects published under the private key of the CA certificate. This the full rsync URI identifiers for each object can be resolved relative to the manifest URI.

Though it would be possible in principle to build up an RPKI tree hierarchy of objects based on key identifiers and hashes [RFC8488], most Relying Party implementations have found it very useful to use rsync URIs for this purpose. Furthermore, these identifiers make it much easier to name object in case of validation problems, which help operators to address issues.

For these reasons, RRDP still includes rsync URIs in the definition of the publish, update and withdraw elements in the snapshot and delta files that it uses. See section 3.5 of [RFC8182]. Thus, objects retrieved through RRDP can be mapped easily to files and URIs, similar to as though rsync would have been used to retrieve them.

4. Updates to RFC6481

OLD:

• The publication repository SHOULD be hosted on a highly available service and high-capacity publication platform.
• The publication repository MUST be available using rsync [RFC5781] [RSYNC]. Support of additional retrieval mechanisms is the choice of the repository operator. The supported retrieval mechanisms MUST be consistent with the accessMethod element value(s) specified in the SIA of the associated CA or EE certificate.

NEW:

• The publication repository MUST be available using the RPKI Repository Delta Protocol [RFC8182]. The RRDP server SHOULD be hosted on a highly available platform.
• The publication repository MAY be available using rsync [RFC5781].
• Support of additional retrieval mechanisms is the choice of the repository operator. The supported retrieval mechanisms MUST be consistent with the accessMethod element value(s) specified in the SIA of the associated CA or EE certificate.

5. Deployment Considerations

Relying Parties can drop support for rsync only when all RPKI repositories support RRDP.

RPKI repositories can drop support for rsync only when Relying Parties support RRDP. Even when all actively maintained RP software packages support RRDP, there will still be old versions of the software in operational use. It is most likely impossible to find that all deployed software supports RRDP, but since RRDP SHOULD be used when it is available [section 3.4.1 of @!RFC8182] it will be possible to measure adoption.

5.1. RRDP support in RPKI Repositories

[This section can be updated during discussion of this document, and may be removed before possible publication.]

(1) in use at various National Internet Registries, as well as other resource holders under RIRs. (2) Software under development.

5.2. RRDP support in Relying Party software

[This section can be updated during discussion of this document, and may be removed before possible publication.]

6. IANA Considerations

This document has no IANA actions.

7. Security Considerations

TBD

8. Acknowledgements

TBD

9. Normative References

Author's Address