SIDROPS

Internet Engineering Task Force (IETF)                             D. Ma
Internet-Draft
Request for Comments: 8897                                          ZDNS
Intended status:
Category: Informational                                          S. Kent
Expires: April 9, 2020
ISSN: 2070-1721                                              Independent
                                                         October 7, 2019
                                                             August 2020

   Requirements for Resource Public Key Infrastructure (RPKI) Relying
                                Parties
                        draft-ietf-sidrops-rp-06

Abstract

   This document provides a single reference point for requirements for
   Relying Party (RP) software for use in the Resource Public Key
   Infrastructure (RPKI) in the context of securing Internet routing. (RPKI).  It cites requirements that appear in several
   RPKI RFCs, making it easier for implementers to become aware of these
   requirements.  This RFC will be updated to reflect changes to the
   requirements that
   are segmented with orthogonal functionalities. and guidance specified in the RFCs discussed herein.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents valid
   approved by the IESG are candidates for a maximum any level of Internet
   Standard; see Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 April 9, 2020.
   https://www.rfc-editor.org/info/rfc8897.

Copyright Notice

   Copyright (c) 2019 2020 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Fetching and Caching RPKI Repository Objects  . . . . . . . .   3
     2.1.  TAL Acquisition Configuration and Processing  . . . . . . . . . . . . .   4
     2.2.  Locating RPKI Objects Using Authority and Subject
           Information Extensions  . . . . . . . . . . . . . . . . .   4
     2.3.  Dealing with Key Rollover . . . . . . . . . . . . . . . .   4
     2.4.  Dealing with Algorithm Transition . . . . . . . . . . . .   4
     2.5.  Strategies for Efficient Cache Maintenance  . . . . . . .   5
   3.  Certificate and CRL Processing  . . . . . . . . . . . . . . .   5
     3.1.  Verifying Resource Certificate and Syntax . . . . . . . .   5
     3.2.  Certificate Path Validation . . . . . . . . . . . . . . .   5
     3.3.  CRL Processing  . . . . . . . . . . . . . . . . . . . . .   6
   4.  Processing RPKI Repository Signed Objects . . . . . . . . . .   6
     4.1.  Basic Signed Object Syntax Checks . . . . . . . . . . . .   6
     4.2.  Syntax and Validation for Each Type of Signed Object  . .   6
       4.2.1.  Manifest  . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.2.  ROA . . . . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.3.  Ghostbusters  . . . . . . . . . . . . . . . . . . . .   7
       4.2.4.  Verifying BGPsec Router Certificate . . . . . . . . .   7
     4.3.  How to Make Use of Manifest Data  . . . . . . . . . . . .   7
     4.4.  What to To Do with Ghostbusters Information  . . . . . . . .   8
   5.  Distributing Validated Cache  . . . . . . . . . . . . . . . .   8
   6.  Local Control . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.
     9.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.
     9.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Acknowledgements
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The

   RPKI Relying Party (RP) software is used by network operators and
   others to acquire and verify Internet Number Resource (INR) data
   stored in the RPKI repository system.  RPKI data, when verified,
   allow
   allows an RP to verify assertions about which Autonomous Systems
   (ASes) are authorized to originate routes for IP address prefixes.
   RPKI data also establishes a binding between public keys and BGP
   routers,
   routers and indicates the AS numbers that each router is authorized
   to represent.

   Noting that the

   The essential requirements imposed on RPs RP software to support
   securing secure
   Internet routing ([RFC6480]) [RFC6480] are scattered throughout numerous RFC documents that are protocol specific or provide best
   practices, as follows:

   RFC 6481
   protocol-specific RFCs and Best Current Practice RFCs.  The following
   RFCs define these requirements:

   *  [RFC6481] (Repository Structure)
   RFC 6482

   *  [RFC6482] (ROA format)
   RFC 6486

   *  [RFC6486] (Manifests)
   RFC 6487

   *  [RFC6487] (Certificate and CRL profile)
   RFC 6488

   *  [RFC6488] (RPKI Signed Objects)
   RFC 6489

   *  [RFC6489] (Key Rollover)
   RFC 6810

   *  [RFC6810] (RPKI to Router Protocol)
   RFC 6916

   *  [RFC6916] (Algorithm Agility)
   RFC 7935

   *  [RFC7935] (Algorithms)
   RFC 8209

   *  [RFC8209] (Router Certificates)
   RFC 8210

   *  [RFC8210] (RPKI to Router Protocol,Version 1)
   RFC 8360

   *  [RFC8360] (Certificate Validation Procedure)
   RFC 8630

   *  [RFC8630] (Trust Anchor Locator)

   This

   The distribution of RPKI RP requirements across these 13 documents
   makes it hard for an implementer to be confident that he/she has
   addressed all of these generalized requirements.  Besides,  Additionally, good software
   engineering calls practice may call for how to segment segmenting the RP system into
   components with orthogonal functionalities, functionalities so that those components could
   may be
   distributed across the operational timeline distributed.  A taxonomy of the user.  Taxonomy of
   generalized collected RP software
   requirements is going to can help have 'the clarify the role of the
   RP' well framed. RP.

   To consolidate RP software requirements in one document, with
   pointers to all the relevant RFCs, this document outlines a set of
   baseline requirements imposed on RPs and provides a single reference
   point for requirements for RP software for use in the RPKI, as segmented with
   orthogonal functionalities:

   o RPKI.  The
   requirements are organized into four groups:

   *  Fetching and Caching RPKI Repository Objects
   o

   *  Processing Certificates and CRLs
   o Certificate Revocation Lists (CRLs)

   *  Processing RPKI Repository Signed Objects
   o

   *  Distributing Validated Cache of the RPKI Data

   This document will be update updated to reflect new or changed requirements
   as these RFCs are updated, updated or new additional RFCs are written.

2.  Fetching and Caching RPKI Repository Objects

   RP software uses synchronization mechanisms supported by targeted
   repositories (e.g., [rsync], [rsync] or RRDP [RFC8182]) to download all RPKI
   changed data
   signed objects in from the repository system and cache them locally.
   The in order to update a local
   cache.  These mechanisms download only those objects that have been
   added or replaced with new versions since the time when the RP most
   recently checked the repository.  RP software validates the RPKI data
   and uses it to generate authenticated data identifying which ASes are
   authorized to originate routes for address prefixes, prefixes and which routers
   are authorized to sign BGP updates on behalf of specified ASes.

2.1.  TAL Acquisition Configuration and Processing

   In the RPKI, each RP chooses its own a set of trust anchors (TAs).
   Consistent with the extant INR allocation hierarchy, the IANA and/or
   the five RIRs Regional Internet Registries (RIRs) are obvious candidates
   to be default TAs for the RP.

   An RP does not retrieve TAs directly.  A set of Trust Anchor Locators
   (TALs) is used by each RP software to retrieve and verify the authenticity
   of each TA.

   TAL acquisition configuration and processing are specified in Section 3 of
   [RFC8630].

2.2.  Locating RPKI Objects Using Authority and Subject Information
      Extensions

   The RPKI repository system is a distributed one, consisting of
   multiple repository instances.  Each repository instance contains one
   or more repository publication points.  An  RP software discovers
   publication points using the Subject Information Access (SIA) and the
   Authority Information Access (AIA) extensions from (validated)
   certificates.

   Section 5 of [RFC6481] specifies how an RP software locates all RPKI
   objects by using the SIA and AIA extensions.  Detailed specifications
   of SIA and AIA extensions in a resource certificate are described in
   Section 4
   Sections 4.8.8 and 4.8.7 of [RFC6487]. [RFC6487], respectively.

2.3.  Dealing with Key Rollover

   An

   RP software takes the key rollover period into account with regard to
   its frequency of synchronization with the RPKI repository system.

   RP software requirements in for dealing with key rollover are described
   in Section 3 of [RFC6489] and Section 3 of [RFC8634].

2.4.  Dealing with Algorithm Transition

   The set of cryptographic algorithms used with the RPKI is expected to
   change over time.  Each RP is expected to be aware of the milestones
   established for the algorithm transition and what actions are
   required at every juncture.

   RP software requirements for dealing with algorithm transition are
   specified in Section 4 of [RFC6916].

2.5.  Strategies for Efficient Cache Maintenance

   Each RP is expected to maintain a local cache of RPKI objects.  The
   cache needs to be as brought up to date and made consistent with the
   repository publication point data as the RP's frequency of checking permits. frequently as allowed by
   repository publication points and by locally selected RP processing
   constraints.

   The last paragraph of Section 5 of [RFC6481] provides guidance for
   maintenance of a local cache.

3.  Certificate and CRL Processing

   The RPKI make makes use of X.509 certificates and CRLs, but it profiles
   these
   the standard formats described in [RFC6487].  The major change to the
   profile established in [RFC5280] is the mandatory use of a new
   extension to
   X.509 certificate in RPKI certificates, defined in [RFC3779].

3.1.  Verifying Resource Certificate and Syntax

   Certificates in the RPKI are called resource certificates, and they
   are required to conform to the profile described in [RFC6487].  An RP
   is required to verify that a resource certificate adheres to the
   profile established by Section 4 of [RFC6487].  This means that all
   extensions mandated by Section 4.8 of [RFC6487] must be present and
   the value of each extension must be within the range specified by this
   RFC.
   [RFC6487].  Moreover, any extension excluded by Section 4.8 of
   [RFC6487] must be omitted.

   Section 7.1 of [RFC6487] gives specifies the procedure that the RP should
   follow to verify resource certificate and syntax. software
   follows when verifying extensions described in [RFC3779].

3.2.  Certificate Path Validation

   The

   Initially, the INRs in the issuer's certificate are required to
   encompass the INRs in the subject's certificate.  This is one of the
   necessary principles of certificate path validation in addition to
   cryptographic verification
   i.e., (i.e., verification of the signature on
   each certificate using the public key of the parent certificate).

   Section 7.2 of [RFC6487] gives specifies the procedure that the RP software
   should follow to perform certificate path validation.

   Certificate

   Certification Authorities (CAs) that want to reduce aspects of
   operational fragility will migrate to the new OIDs [RFC8360],
   informing the RP of
   using software to use an alternative RPKI validation
   algorithm.  An RP is expected to support the amended procedure to
   handle with accidental over-claim. overclaiming, which is described in Section 4 of
   [RFC8360].

3.3.  CRL Processing

   The CRL processing requirements imposed on CAs and RP RPs are described
   in Section 5 of [RFC6487].  CRLs in the RPKI are tightly constrained;
   only the AuthorityKeyIndetifier AuthorityKeyIndentifier (Section 4.8.3 of [RFC6487]) and
   CRLNumber (Section 5.2.3 of [RFC5280]) extensions are allowed, and
   they are required to be present.  No other CRL extensions are
   allowed, and no CRLEntry extensions are permitted.  RPs are  RP software is
   required to verify that these constraints have been met.  Each CRL in
   the RPKI must be verified using the public key from the certificate
   of the CA that issued the CRL.

   In the RPKI, RPs are expected to pay extra attention when dealing
   with a CRL that is not consistent with the Manifest manifest associated with
   the publication point associated with the CRL.

   Processing of a CRL that is not consistent with a manifest is a
   matter of local policy, as described in the fourth fifth paragraph of
   Section 6.6 of [RFC6486].

4.  Processing RPKI Repository Signed Objects

4.1.  Basic Signed Object Syntax Checks

   Before an RP can use a signed object from the RPKI repository, the RP
   software is required to check the signed object signed-object syntax.

   Section 3 of [RFC6488] lists all the steps that the RP software is
   required to execute in order to validate the top level top-level syntax of a
   repository signed object.

   Note that these checks are necessary, necessary but not sufficient.  Additional
   validation checks must be performed based on the specific type of
   signed object. object, as described in Section 4.2.

4.2.  Syntax and Validation for Each Type of Signed Object

4.2.1.  Manifest

   To determine whether a manifest is valid, the RP software is required to
   perform manifest-specific checks in addition to those the generic signed-
   object checks specified in [RFC6488].

   Specific checks for a Manifest manifest are described in Section 4 of
   [RFC6486].  If any of these checks fails, fail, indicating that the manifest
   is invalid, then the manifest will be discarded discarded, and treated RP software will
   act as though no manifest were present.

4.2.2.  ROA

   To validate a ROA, the Route Origin Authorization (ROA), RP software is
   required to perform all the checks specified in [RFC6488] as well as the additional
   additional, ROA-specific validation steps.  The IP address delegation Address Delegation
   extension [RFC3779] present in the end-entity (EE) certificate
   (contained within the
   ROA), ROA) must encompass each of the IP address
   prefix(es) in the ROA.

   More details for ROA validation are specified in Section 4 of
   [RFC6482].

4.2.3.  Ghostbusters

   The Ghostbusters Record is optional; a publication point in the RPKI
   can have zero or more associated Ghostbuster Ghostbusters Records.  If a CA has
   at least one Ghostbuster Ghostbusters Record, RP software is required to verify
   that this Ghostbusters Record conforms to the syntax of signed object
   objects defined in [RFC6488].

   The payload of this signed object is a (severely) profiled vCard.  An  RP
   software is required to verify that the payload of Ghostbusters
   conforms to format as profiled in [RFC6493].

4.2.4.  Verifying BGPsec Router Certificate

   A BGPsec Router Certificate is a resource certificate, so it is
   required to comply with [RFC6487].  Additionally, the certificate
   must contain an AS Identifier Delegation extension, extension (Section 4.8.11 of
   [RFC6487]) and must not contain an IP Address Delegation extension. extension
   (Section 4.8.10 of [RFC6487]).  The validation procedure used for
   BGPsec Router Certificates is identical analogous to the validation procedure
   described in Section 7 of [RFC6487], but using it uses the constraints applied come from specification of
   defined in Section 7 3 of [RFC8209].

   Note that the cryptographic algorithms used by BGPsec routers are
   found in [RFC8208]. [RFC8608].  Currently, the algorithms specified in
   [RFC8208]and [RFC8608]
   and [RFC7935] are different.  BGPsec RPs RP software will need to support
   algorithms that are used to validate BGPsec signatures as well as the
   algorithms that are needed to validate signatures on BGPsec
   certificates, RPKI CA certificates, and RPKI CRLs.

4.3.  How to Make Use of Manifest Data

   For a given publication point, the RP software ought to perform tests, as
   specified in Section 6.1 of [RFC6486], to determine the state of the
   Manifest
   manifest at the publication point.  A Manifest manifest can be classified as
   either valid or invalid, and a valid Manifest manifest is either current and or
   stale.  An RP decides how to make use of a Manifest manifest based on its
   state, according to local (RP) policy.

   If there are valid objects in a publication point that are not
   present on a Manifest, manifest, [RFC6486] does not mandate specific RP
   behavior with respect to such objects.  However, most RP software
   ignores such objects and the authors of this document suggest this
   behavior be adopted uniformly.

   In the absence of a Manifest, manifest, an RP is expected to accept all valid
   signed objects present in the publication point. point (see Section 6.2 of
   [RFC6486]).  If a Manifest manifest is stale or invalid (see [RFC6486]) and an RP has no way
   to acquire a more recently recent valid Manifest, manifest, the RP is expected to
   contact the repository manager via Ghostbusters record Records and
   thereafter make
   decision decisions according to local (RP) policy. policy (see
   Sections 6.3 and 6.4 of [RFC6486]).

4.4.  What to To Do with Ghostbusters Information

   An

   RP software may encounter a stale Manifest manifest or CRL, or an expired CA
   certificate or ROA at a publication point.  An RP is expected to use
   the information from the Ghostbusters record Records to contact the
   maintainer of the publication point where any stale/expired objects
   were encountered.  The intent here is to encourage the relevant CA
   and/or repository manager to update the slate stale or expired objects.

5.  Distributing Validated Cache

   On a periodic basis, BGP speakers within an AS request updated
   validated origin AS data and router/ASN data from the (local)
   validated cache of RPKI data.  The RP may either transfer the
   validated data to the BGP speakers directly, or it may transfer the
   validated data to a cache server that is responsible for provisioning
   such data to BGP speakers.  The specification specifications of the protocol
   designed to deliver validated cache data to a BGP Speaker is are
   provided in [RFC6810] and [RFC8210].

6.  Local Control

   ISPs may want to establish a local view of exceptions to the RPKI
   data in the form of local filters and additions.  For instance, a
   network operator might wish to make use of a local override
   capability to protect routes from adverse actions [RFC8211] . [RFC8211].  The
   mechanisms developed to provide this capability to network operators
   are called "Simplified Simplified Local Internet Number Resource Management with
   the RPKI (SLURM).  If an ISP wants to implement SLURM, its RP system
   can follow the instruction specified in [RFC8416] . [RFC8416].

7.  Security Considerations

   This document does not introduce any new security considerations; it
   is a resource for implementers.  The RP links the RPKI provisioning
   side and the routing system, establishing the a verified, local view of
   global RPKI data to BGP speakers.  The security of the RP is critical to
   for exchanging BGP messages exchanging.  The messages.  Each RP implementation is expected to
   offer cache backup management to facilitate recovery from outage state.  The outages.
   RP implementation also software should also support application of secure transport (e.g., IPsec
   [RFC4301]) that is able to can protect validated cache delivery in a an unsafe
   environment.  This document highlights many validation actions
   applied to RPKI signed objects, an essential element of secure
   operation of RPKI security.

8.  IANA Considerations

   This document has no actions for IANA. IANA actions.

9.

10.  References

10.1.

9.1.  Normative References

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779,
              DOI 10.17487/RFC3779, June 2004,
              <https://www.rfc-editor.org/info/rfc3779>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
              Resource Certificate Repository Structure", RFC 6481,
              DOI 10.17487/RFC6481, February 2012,
              <https://www.rfc-editor.org/info/rfc6481>.

   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)", RFC 6482,
              DOI 10.17487/RFC6482, February 2012,
              <https://www.rfc-editor.org/info/rfc6482>.

   [RFC6486]  Austein, R., Huston, G., Kent, S., and M. Lepinski,
              "Manifests for the Resource Public Key Infrastructure
              (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
              <https://www.rfc-editor.org/info/rfc6486>.

   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", RFC 6487,
              DOI 10.17487/RFC6487, February 2012,
              <https://www.rfc-editor.org/info/rfc6487>.

   [RFC6488]  Lepinski, M., Chi, A., and S. Kent, "Signed Object
              Template for the Resource Public Key Infrastructure
              (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
              <https://www.rfc-editor.org/info/rfc6488>.

   [RFC6489]  Huston, G., Michaelson, G., and S. Kent, "Certification
              Authority (CA) Key Rollover in the Resource Public Key
              Infrastructure (RPKI)", BCP 174, RFC 6489,
              DOI 10.17487/RFC6489, February 2012,
              <https://www.rfc-editor.org/info/rfc6489>.

   [RFC6493]  Bush, R., "The Resource Public Key Infrastructure (RPKI)
              Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
              February 2012, <https://www.rfc-editor.org/info/rfc6493>.

   [RFC6810]  Bush, R. and R. Austein, "The Resource Public Key
              Infrastructure (RPKI) to Router Protocol", RFC 6810,
              DOI 10.17487/RFC6810, January 2013,
              <https://www.rfc-editor.org/info/rfc6810>.

   [RFC6916]  Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
              Procedure for the Resource Public Key Infrastructure
              (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
              2013, <https://www.rfc-editor.org/info/rfc6916>.

   [RFC7935]  Huston, G. and G. Michaelson, Ed., "The Profile for
              Algorithms and Key Sizes for Use in the Resource Public
              Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
              August 2016, <https://www.rfc-editor.org/info/rfc7935>.

   [RFC8208]  Turner, S. and O. Borchert, "BGPsec Algorithms, Key
              Formats, and Signature Formats", RFC 8208,
              DOI 10.17487/RFC8208, September 2017,
              <https://www.rfc-editor.org/info/rfc8208>.

   [RFC8209]  Reynolds, M., Turner, S., and S. Kent, "A Profile for
              BGPsec Router Certificates, Certificate Revocation Lists,
              and Certification Requests", RFC 8209,
              DOI 10.17487/RFC8209, September 2017,
              <https://www.rfc-editor.org/info/rfc8209>.

   [RFC8210]  Bush, R. and R. Austein, "The Resource Public Key
              Infrastructure (RPKI) to Router Protocol, Version 1",
              RFC 8210, DOI 10.17487/RFC8210, September 2017,
              <https://www.rfc-editor.org/info/rfc8210>.

   [RFC8360]  Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T.,
              Newton, A., and D. Shaw, "Resource Public Key
              Infrastructure (RPKI) Validation Reconsidered", RFC 8360,
              DOI 10.17487/RFC8360, April 2018,
              <https://www.rfc-editor.org/info/rfc8360>.

   [RFC8608]  Turner, S. and O. Borchert, "BGPsec Algorithms, Key
              Formats, and Signature Formats", RFC 8608,
              DOI 10.17487/RFC8608, June 2019,
              <https://www.rfc-editor.org/info/rfc8608>.

   [RFC8630]  Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
              Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
              Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630,
              August 2019, <https://www.rfc-editor.org/info/rfc8630>.

10.2.

   [RFC8634]  Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
              Certificate Rollover", BCP 224, RFC 8634,
              DOI 10.17487/RFC8634, August 2019,
              <https://www.rfc-editor.org/info/rfc8634>.

9.2.  Informative References

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <https://www.rfc-editor.org/info/rfc6480>.

   [RFC6489]  Huston, G., Michaelson, G., and S. Kent, "Certification
              Authority (CA) Key Rollover in the Resource Public Key
              Infrastructure (RPKI)", BCP 174, RFC 6489,
              DOI 10.17487/RFC6489, February 2012,
              <https://www.rfc-editor.org/info/rfc6489>.

   [RFC6916]  Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
              Procedure for the Resource Public Key Infrastructure
              (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
              2013, <https://www.rfc-editor.org/info/rfc6916>.

   [RFC8182]  Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
              "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
              DOI 10.17487/RFC8182, July 2017,
              <https://www.rfc-editor.org/info/rfc8182>.

   [RFC8211]  Kent, S. and D. Ma, "Adverse Actions by a Certification
              Authority (CA) or Repository Manager in the Resource
              Public Key Infrastructure (RPKI)", RFC 8211,
              DOI 10.17487/RFC8211, September 2017,
              <https://www.rfc-editor.org/info/rfc8211>.

   [RFC8416]  Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified
              Local Internet Number Resource Management with the RPKI
              (SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018,
              <https://www.rfc-editor.org/info/rfc8416>.

   [RFC8634]  Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
              Certificate Rollover", BCP 224, RFC 8634,
              DOI 10.17487/RFC8634, August 2019,
              <https://www.rfc-editor.org/info/rfc8634>.

   [rsync]    "rsync web page",    "rsync", <http://rsync.samba.org/>.

Acknowledgements

   The authors thank David Mandelberg, Wei Wang, Tim Bruijnzeels, George
   Michaelson
   Michaelson, and Oleg Muravskiy for their review, feedback feedback, and
   editorial assistance in preparing this document.

Authors' Addresses

   Di Ma
   ZDNS
   4 South 4th St. Zhongguancun
   Haidian, Beijing
   Haidian
   Beijing, 100190
   China

   Email: madi@zdns.cn

   Stephen Kent
   Independent

   Email: kent@alum.mit.edu