draft-ietf-sidrops-rp-06.txt   rfc8897.txt 
SIDROPS D. Ma Internet Engineering Task Force (IETF) D. Ma
Internet-Draft ZDNS Request for Comments: 8897 ZDNS
Intended status: Informational S. Kent Category: Informational S. Kent
Expires: April 9, 2020 Independent ISSN: 2070-1721 Independent
October 7, 2019 September 2020
Requirements for Resource Public Key Infrastructure (RPKI) Relying Requirements for Resource Public Key Infrastructure (RPKI) Relying
Parties Parties
draft-ietf-sidrops-rp-06
Abstract Abstract
This document provides a single reference point for requirements for This document provides a single reference point for requirements for
Relying Party (RP) software for use in the Resource Public Key Relying Party (RP) software for use in the Resource Public Key
Infrastructure (RPKI) in the context of securing Internet routing. Infrastructure (RPKI). It cites requirements that appear in several
It cites requirements that appear in several RPKI RFCs, making it RPKI RFCs, making it easier for implementers to become aware of these
easier for implementers to become aware of these requirements that requirements. Over time, this RFC will be updated to reflect changes
are segmented with orthogonal functionalities. to the requirements and guidance specified in the RFCs discussed
herein.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on April 9, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8897.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Fetching and Caching RPKI Repository Objects . . . . . . . . 3 2. Fetching and Caching RPKI Repository Objects
2.1. TAL Acquisition and Processing . . . . . . . . . . . . . 4 2.1. TAL Configuration and Processing
2.2. Locating RPKI Objects Using Authority and Subject 2.2. Locating RPKI Objects Using Authority and Subject
Information Extensions . . . . . . . . . . . . . . . . . 4 Information Extensions
2.3. Dealing with Key Rollover . . . . . . . . . . . . . . . . 4 2.3. Dealing with Key Rollover
2.4. Dealing with Algorithm Transition . . . . . . . . . . . . 4 2.4. Dealing with Algorithm Transition
2.5. Strategies for Efficient Cache Maintenance . . . . . . . 5 2.5. Strategies for Efficient Cache Maintenance
3. Certificate and CRL Processing . . . . . . . . . . . . . . . 5 3. Certificate and CRL Processing
3.1. Verifying Resource Certificate and Syntax . . . . . . . . 5 3.1. Verifying Resource Certificate and Syntax
3.2. Certificate Path Validation . . . . . . . . . . . . . . . 5 3.2. Certificate Path Validation
3.3. CRL Processing . . . . . . . . . . . . . . . . . . . . . 6 3.3. CRL Processing
4. Processing RPKI Repository Signed Objects . . . . . . . . . . 6 4. Processing RPKI Repository Signed Objects
4.1. Basic Signed Object Syntax Checks . . . . . . . . . . . . 6 4.1. Basic Signed Object Syntax Checks
4.2. Syntax and Validation for Each Type of Signed Object . . 6 4.2. Syntax and Validation for Each Type of Signed Object
4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Manifest
4.2.2. ROA . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. ROA
4.2.3. Ghostbusters . . . . . . . . . . . . . . . . . . . . 7 4.2.3. Ghostbusters
4.2.4. Verifying BGPsec Router Certificate . . . . . . . . . 7 4.2.4. Verifying BGPsec Router Certificate
4.3. How to Make Use of Manifest Data . . . . . . . . . . . . 7 4.3. How to Make Use of Manifest Data
4.4. What to Do with Ghostbusters Information . . . . . . . . 8 4.4. What To Do with Ghostbusters Information
5. Distributing Validated Cache . . . . . . . . . . . . . . . . 8 5. Distributing Validated Cache
6. Local Control . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Local Control
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses
1. Introduction 1. Introduction
The RPKI Relying Party (RP) software is used by network operators and RPKI Relying Party (RP) software is used by network operators and
others to acquire and verify Internet Number Resource (INR) data others to acquire and verify Internet Number Resource (INR) data
stored in the RPKI repository system. RPKI data, when verified, stored in the RPKI repository system. RPKI data, when verified,
allow an RP to verify assertions about which Autonomous Systems allows an RP to verify assertions about which Autonomous Systems
(ASes) are authorized to originate routes for IP address prefixes. (ASes) are authorized to originate routes for IP address prefixes.
RPKI data also establishes binding between public keys and BGP RPKI data also establishes a binding between public keys and BGP
routers, and indicates the AS numbers that each router is authorized routers and indicates the AS numbers that each router is authorized
to represent. to represent.
Noting that the essential requirements imposed on RPs to support The essential requirements imposed on RP software to support secure
securing Internet routing ([RFC6480]) are scattered throughout Internet routing [RFC6480] are scattered throughout numerous
numerous RFC documents that are protocol specific or provide best protocol-specific RFCs and Best Current Practice RFCs. The following
practices, as follows: RFCs define these requirements:
RFC 6481 (Repository Structure) RFC 6481 (Repository Structure)
RFC 6482 (ROA format) RFC 6482 (ROA format)
RFC 6486 (Manifests) RFC 6486 (Manifests)
RFC 6487 (Certificate and CRL profile) RFC 6487 (Certificate and CRL profile)
RFC 6488 (RPKI Signed Objects) RFC 6488 (RPKI Signed Objects)
RFC 6489 (Key Rollover) RFC 6489 (Key Rollover)
RFC 6810 (RPKI to Router Protocol) RFC 6810 (RPKI to Router Protocol)
RFC 6916 (Algorithm Agility) RFC 6916 (Algorithm Agility)
RFC 7935 (Algorithms) RFC 7935 (Algorithms)
RFC 8209 (Router Certificates) RFC 8209 (Router Certificates)
RFC 8210 (RPKI to Router Protocol,Version 1) RFC 8210 (RPKI to Router Protocol, Version 1)
RFC 8360 (Certificate Validation Procedure) RFC 8360 (Certificate Validation Procedure)
RFC 8630 (Trust Anchor Locator) RFC 8630 (Trust Anchor Locator)
This makes it hard for an implementer to be confident that he/she has The distribution of RPKI RP requirements across these 13 documents
addressed all of these generalized requirements. Besides, software makes it hard for an implementer to be confident that he/she has
engineering calls for how to segment the RP system into components addressed all of these requirements. Additionally, good software
with orthogonal functionalities, so that those components could be engineering practice may call for segmenting the RP system into
distributed across the operational timeline of the user. Taxonomy of components with orthogonal functionalities so that those components
generalized RP requirements is going to help have 'the role of the may be distributed. A taxonomy of the collected RP software
RP' well framed. requirements can help clarify the role of the RP.
To consolidate RP requirements in one document, with pointers to all To consolidate RP software requirements in one document, with
the relevant RFCs, this document outlines a set of baseline pointers to all the relevant RFCs, this document outlines a set of
requirements imposed on RPs and provides a single reference point for baseline requirements imposed on RPs and provides a single reference
requirements for RP software for use in the RPKI, as segmented with point for requirements for RP software for use in the RPKI. The
orthogonal functionalities: requirements are organized into four groups:
o Fetching and Caching RPKI Repository Objects * Fetching and Caching RPKI Repository Objects
o Processing Certificates and CRLs
o Processing RPKI Repository Signed Objects
o Distributing Validated Cache of the RPKI Data
This document will be update to reflect new or changed requirements * Processing Certificates and Certificate Revocation Lists (CRLs)
as these RFCs are updated, or new RFCs are written.
* Processing RPKI Repository Signed Objects
* Distributing Validated Cache of the RPKI Data
This document will be updated to reflect new or changed requirements
as these RFCs are updated or additional RFCs are written.
2. Fetching and Caching RPKI Repository Objects 2. Fetching and Caching RPKI Repository Objects
RP software uses synchronization mechanisms supported by targeted RP software uses synchronization mechanisms supported by targeted
repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI repositories (e.g., [rsync] or RRDP [RFC8182]) to download RPKI
changed data objects in the repository system and cache them locally. signed objects from the repository system in order to update a local
The software validates the RPKI data and uses it to generate cache. These mechanisms download only those objects that have been
authenticated data identifying which ASes are authorized to originate added or replaced with new versions since the time when the RP most
routes for address prefixes, and which routers are authorized to sign recently checked the repository. RP software validates the RPKI data
BGP updates on behalf of ASes. and uses it to generate authenticated data identifying which ASes are
authorized to originate routes for address prefixes and which routers
are authorized to sign BGP updates on behalf of specified ASes.
2.1. TAL Acquisition and Processing 2.1. TAL Configuration and Processing
In the RPKI, each RP chooses its own set of trust anchors (TAs). In the RPKI, each RP chooses a set of trust anchors (TAs).
Consistent with the extant INR allocation hierarchy, the IANA and/or Consistent with the extant INR allocation hierarchy, the IANA and/or
the five RIRs are obvious candidates to be default TAs for the RP. the five 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 An RP does not retrieve TAs directly. A set of Trust Anchor Locators
(TALs) is used by each RP to retrieve and verify the authenticity of (TALs) is used by RP software to retrieve and verify the authenticity
each TA. of each TA.
TAL acquisition and processing are specified in Section 3 of TAL configuration and processing are specified in Section 3 of
[RFC8630]. [RFC8630].
2.2. Locating RPKI Objects Using Authority and Subject Information 2.2. Locating RPKI Objects Using Authority and Subject Information
Extensions Extensions
The RPKI repository system is a distributed one, consisting of The RPKI repository system is a distributed one, consisting of
multiple repository instances. Each repository instance contains one multiple repository instances. Each repository instance contains one
or more repository publication points. An RP discovers publication or more repository publication points. RP software discovers
points using the Subject Information Access (SIA) and the Authority publication points using the Subject Information Access (SIA) and the
Information Access (AIA) extensions from (validated) certificates. Authority Information Access (AIA) extensions from (validated)
certificates.
Section 5 of [RFC6481] specifies how an RP locates all RPKI objects Section 5 of [RFC6481] specifies how RP software locates all RPKI
by using the SIA and AIA extensions. Detailed specifications of SIA objects by using the SIA and AIA extensions. Detailed specifications
and AIA extensions in a resource certificate are described in of SIA and AIA extensions in a resource certificate are described in
Section 4 of [RFC6487]. Sections 4.8.8 and 4.8.7 of [RFC6487], respectively.
2.3. Dealing with Key Rollover 2.3. Dealing with Key Rollover
An RP takes the key rollover period into account with regard to its RP software takes the key rollover period into account with regard to
frequency of synchronization with RPKI repository system. its frequency of synchronization with the RPKI repository system.
RP requirements in dealing with key rollover are described in RP software requirements for dealing with key rollover are described
Section 3 of [RFC6489] and Section 3 of [RFC8634]. in Section 3 of [RFC6489] and Section 3 of [RFC8634].
2.4. Dealing with Algorithm Transition 2.4. Dealing with Algorithm Transition
The set of cryptographic algorithms used with the RPKI is expected to 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 change over time. Each RP is expected to be aware of the milestones
established for the algorithm transition and what actions are established for the algorithm transition and what actions are
required at every juncture. required at every juncture.
RP requirements for dealing with algorithm transition are specified RP software requirements for dealing with algorithm transition are
in Section 4 of [RFC6916]. specified in Section 4 of [RFC6916].
2.5. Strategies for Efficient Cache Maintenance 2.5. Strategies for Efficient Cache Maintenance
Each RP is expected to maintain a local cache of RPKI objects. The Each RP is expected to maintain a local cache of RPKI objects. The
cache needs to be as up to date and consistent with repository cache needs to be brought up to date and made consistent with the
publication point data as the RP's frequency of checking permits. repository publication point data as 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 The last paragraph of Section 5 of [RFC6481] provides guidance for
maintenance of a local cache. maintenance of a local cache.
3. Certificate and CRL Processing 3. Certificate and CRL Processing
The RPKI make use of X.509 certificates and CRLs, but it profiles The RPKI makes use of X.509 certificates and CRLs, but it profiles
these standard formats [RFC6487]. The major change to the profile the standard formats described in [RFC6487]. The major change to the
established in [RFC5280] is the mandatory use of a new extension to profile established in [RFC5280] is the mandatory use of a new
X.509 certificate [RFC3779]. extension in RPKI certificates, defined in [RFC3779].
3.1. Verifying Resource Certificate and Syntax 3.1. Verifying Resource Certificate and Syntax
Certificates in the RPKI are called resource certificates, and they Certificates in the RPKI are called resource certificates, and they
are required to conform to the profile [RFC6487]. An RP is required are required to conform to the profile described in [RFC6487]. An RP
to verify that a resource certificate adheres to the profile is required to verify that a resource certificate adheres to the
established by Section 4 of [RFC6487]. This means that all profile established by Section 4 of [RFC6487]. This means that all
extensions mandated by Section 4.8 of [RFC6487] must be present and extensions mandated by Section 4.8 of [RFC6487] must be present and
value of each extension must be within the range specified by this the value of each extension must be within the range specified by
RFC. Moreover, any extension excluded by Section 4.8 of [RFC6487] [RFC6487]. Moreover, any extension excluded by Section 4.8 of
must be omitted. [RFC6487] must be omitted.
Section 7.1 of [RFC6487] gives the procedure that the RP should Section 7.1 of [RFC6487] specifies the procedure that RP software
follow to verify resource certificate and syntax. follows when verifying extensions described in [RFC3779].
3.2. Certificate Path Validation 3.2. Certificate Path Validation
The INRs in issuer's certificate are required to encompass the INRs Initially, the INRs in the issuer's certificate are required to
in the subject's certificate. This is one of necessary principles of encompass the INRs in the subject's certificate. This is one of the
certificate path validation in addition to cryptographic verification necessary principles of certificate path validation in addition to
i.e., verification of the signature on each certificate using the cryptographic verification (i.e., verification of the signature on
public key of the parent certificate). each certificate using the public key of the parent certificate).
Section 7.2 of [RFC6487] gives the procedure that the RP should Section 7.2 of [RFC6487] specifies the procedure that RP software
follow to perform certificate path validation. should follow to perform certificate path validation.
Certificate Authorities that want to reduce aspects of operational Certification Authorities (CAs) that want to reduce aspects of
fragility will migrate to the new OIDs [RFC8360], informing the RP of operational fragility will migrate to the new OIDs [RFC8360],
using an alternative RPKI validation algorithm. An RP is expected to informing RP software to use an alternative RPKI validation
support the amended procedure to handle with accidental over-claim. algorithm. An RP is expected to support the amended procedure to
handle accidental overclaiming, which is described in Section 4 of
[RFC8360].
3.3. CRL Processing 3.3. CRL Processing
The CRL processing requirements imposed on CAs and RP are described The CRL processing requirements imposed on CAs and RPs are described
in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained; in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained;
only the AuthorityKeyIndetifier and CRLNumber extensions are allowed, only the AuthorityKeyIdentifier (Section 4.8.3 of [RFC6487]) and
and they are required to be present. No other CRL extensions are CRLNumber (Section 5.2.3 of [RFC5280]) extensions are allowed, and
allowed, and no CRLEntry extensions are permitted. RPs are required they are required to be present. No other CRL extensions are
to verify that these constraints have been met. Each CRL in the RPKI allowed, and no CRLEntry extensions are permitted. RP software is
must be verified using the public key from the certificate of the CA required to verify that these constraints have been met. Each CRL in
that issued the CRL. 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 In the RPKI, RPs are expected to pay extra attention when dealing
with a CRL that is not consistent with the Manifest associated with with a CRL that is not consistent with the manifest associated with
the publication point associated with the CRL. the publication point associated with the CRL.
Processing of a CRL that is not consistent with a manifest is a Processing of a CRL that is not consistent with a manifest is a
matter of local policy, as described in the fourth paragraph of matter of local policy, as described in the fifth paragraph of
Section 6.6 of [RFC6486]. Section 6.6 of [RFC6486].
4. Processing RPKI Repository Signed Objects 4. Processing RPKI Repository Signed Objects
4.1. Basic Signed Object Syntax Checks 4.1. Basic Signed Object Syntax Checks
Before an RP can use a signed object from the RPKI repository, the RP Before an RP can use a signed object from the RPKI repository, RP
is required to check the signed object syntax. software is required to check the signed-object syntax.
Section 3 of [RFC6488] lists all the steps that the RP is required to Section 3 of [RFC6488] lists all the steps that RP software is
execute in order to validate the top level syntax of a repository required to execute in order to validate the top-level syntax of a
signed object. repository signed object.
Note that these checks are necessary, but not sufficient. Additional Note that these checks are necessary but not sufficient. Additional
validation checks must be performed based on the specific type of validation checks must be performed based on the specific type of
signed object. signed object, as described in Section 4.2.
4.2. Syntax and Validation for Each Type of Signed Object 4.2. Syntax and Validation for Each Type of Signed Object
4.2.1. Manifest 4.2.1. Manifest
To determine whether a manifest is valid, the RP is required to To determine whether a manifest is valid, RP software is required to
perform manifest-specific checks in addition to those specified in perform manifest-specific checks in addition to the generic signed-
[RFC6488]. object checks specified in [RFC6488].
Specific checks for a Manifest are described in Section 4 of Specific checks for a manifest are described in Section 4 of
[RFC6486]. If any of these checks fails, indicating that the [RFC6486]. If any of these checks fail, indicating that the manifest
manifest is invalid, then the manifest will be discarded and treated is invalid, then the manifest will be discarded, and RP software will
as though no manifest were present. act as though no manifest were present.
4.2.2. ROA 4.2.2. ROA
To validate a ROA, the RP is required perform all the checks To validate a Route Origin Authorization (ROA), RP software is
specified in [RFC6488] as well as the additional ROA-specific required to perform all the checks specified in [RFC6488] as well as
validation steps. The IP address delegation extension [RFC3779] additional, ROA-specific validation steps. The IP Address Delegation
present in the end-entity (EE) certificate (contained within the extension [RFC3779] present in the end-entity (EE) certificate
ROA), must encompass each of the IP address prefix(es) in the ROA. (contained within the ROA) must encompass each of the IP address
prefix(es) in the ROA.
More details for ROA validation are specified in Section 4 of More details for ROA validation are specified in Section 4 of
[RFC6482]. [RFC6482].
4.2.3. Ghostbusters 4.2.3. Ghostbusters
The Ghostbusters Record is optional; a publication point in the RPKI The Ghostbusters Record is optional; a publication point in the RPKI
can have zero or more associated Ghostbuster Records. If a CA has at can have zero or more associated Ghostbusters Records. If a CA has
least one Ghostbuster Record, RP is required to verify that this at least one Ghostbusters Record, RP software is required to verify
Ghostbusters Record conforms to the syntax of signed object defined that this Ghostbusters Record conforms to the syntax of signed
in [RFC6488]. objects defined in [RFC6488].
The payload of this signed object is a (severely) profiled vCard. An The payload of this signed object is a (severely) profiled vCard. RP
RP is required to verify that the payload of Ghostbusters conforms to software is required to verify that the payload of Ghostbusters
format as profiled in [RFC6493]. conforms to format as profiled in [RFC6493].
4.2.4. Verifying BGPsec Router Certificate 4.2.4. Verifying BGPsec Router Certificate
A BGPsec Router Certificate is a resource certificate, so it is A BGPsec Router Certificate is a resource certificate, so it is
required to comply with [RFC6487]. Additionally, the certificate required to comply with [RFC6487]. Additionally, the certificate
must contain an AS Identifier Delegation extension, and must not must contain an AS Identifier Delegation extension (Section 4.8.11 of
contain an IP Address Delegation extension. The validation procedure [RFC6487]) and must not contain an IP Address Delegation extension
used for BGPsec Router Certificates is identical to the validation (Section 4.8.10 of [RFC6487]). The validation procedure used for
procedure described in Section 7 of [RFC6487], but using the BGPsec Router Certificates is analogous to the validation procedure
constraints applied come from specification of Section 7 of described in Section 7 of [RFC6487], but it uses the constraints
[RFC8209]. defined in Section 3 of [RFC8209].
Note that the cryptographic algorithms used by BGPsec routers are Note that the cryptographic algorithms used by BGPsec routers are
found in [RFC8208]. Currently, the algorithms specified in found in [RFC8608]. Currently, the algorithms specified in [RFC8608]
[RFC8208]and [RFC7935] are different. BGPsec RPs will need to and [RFC7935] are different. BGPsec RP software will need to support
support algorithms that are used to validate BGPsec signatures as algorithms that are used to validate BGPsec signatures as well as the
well as the algorithms that are needed to validate signatures on algorithms that are needed to validate signatures on BGPsec
BGPsec certificates, RPKI CA certificates, and RPKI CRLs. certificates, RPKI CA certificates, and RPKI CRLs.
4.3. How to Make Use of Manifest Data 4.3. How to Make Use of Manifest Data
For a given publication point, the RP ought to perform tests, as For a given publication point, RP software ought to perform tests, as
specified in Section 6.1 of [RFC6486], to determine the state of the specified in Section 6.1 of [RFC6486], to determine the state of the
Manifest at the publication point. A Manifest can be classified as manifest at the publication point. A manifest can be classified as
either valid or invalid, and a valid Manifest is either current and either valid or invalid, and a valid manifest is either current or
stale. An RP decides how to make use of a Manifest based on its stale. An RP decides how to make use of a manifest based on its
state, according to local (RP) policy. state, according to local (RP) policy.
If there are valid objects in a publication point that are not If there are valid objects in a publication point that are not
present on a Manifest, [RFC6486] does not mandate specific RP present on a manifest, [RFC6486] does not mandate specific RP
behavior with respect to such objects. However, most RP software behavior with respect to such objects.
ignores such objects and the authors of this document suggest this
behavior be adopted uniformly.
In the absence of a Manifest, an RP is expected to accept all valid In the absence of a manifest, an RP is expected to accept all valid
signed objects present in the publication point. If a Manifest is signed objects present in the publication point (see Section 6.2 of
stale or invalid (see [RFC6486]) and an RP has no way to acquire a [RFC6486]). If a manifest is stale or invalid and an RP has no way
more recently valid Manifest, the RP is expected to contact the to acquire a more recent valid manifest, the RP is expected to
repository manager via Ghostbusters record and thereafter make contact the repository manager via Ghostbusters Records and
decision according to local (RP) policy. thereafter make decisions according to local (RP) policy (see
Sections 6.3 and 6.4 of [RFC6486]).
4.4. What to Do with Ghostbusters Information 4.4. What To Do with Ghostbusters Information
An RP may encounter a stale Manifest or CRL, or an expired CA RP software may encounter a stale manifest or CRL, or an expired CA
certificate or ROA at a publication point. An RP is expected to use certificate or ROA at a publication point. An RP is expected to use
the information from the Ghostbusters record to contact the the information from the Ghostbusters Records to contact the
maintainer of the publication point where any stale/expired objects maintainer of the publication point where any stale/expired objects
were encountered. The intent here is to encourage the relevant CA were encountered. The intent here is to encourage the relevant CA
and/or repository manager to update the slate or expired objects. and/or repository manager to update the stale or expired objects.
5. Distributing Validated Cache 5. Distributing Validated Cache
On a periodic basis, BGP speakers within an AS request updated On a periodic basis, BGP speakers within an AS request updated
validated origin AS data and router/ASN data from the validated cache validated origin AS data and router/ASN data from the (local)
of RPKI data. The RP may either transfer the validated data to the validated cache of RPKI data. The RP may either transfer the
BGP speakers directly, or it may transfer the validated data to a validated data to the BGP speakers directly, or it may transfer the
cache server that is responsible for provisioning such data to BGP validated data to a cache server that is responsible for provisioning
speakers. The specification of the protocol designed to deliver such data to BGP speakers. The specifications of the protocol
validated cache data to a BGP Speaker is provided in [RFC6810] and designed to deliver validated cache data to a BGP Speaker are
[RFC8210]. provided in [RFC6810] and [RFC8210].
6. Local Control 6. Local Control
ISPs may want to establish a local view of exceptions to the RPKI 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 data in the form of local filters and additions. For instance, a
network operator might wish to make use of a local override network operator might wish to make use of a local override
capability to protect routes from adverse actions [RFC8211] . The capability to protect routes from adverse actions [RFC8211]. The
mechanisms developed to provide this capability to network operators mechanisms developed to provide this capability to network operators
are called "Simplified Local Internet Number Resource Management with are called Simplified Local Internet Number Resource Management with
the RPKI (SLURM). If an ISP wants to implement SLURM, its RP system the RPKI (SLURM). If an ISP wants to implement SLURM, its RP system
can follow the instruction specified in [RFC8416] . can follow the instruction specified in [RFC8416].
7. Security Considerations 7. Security Considerations
The RP links the RPKI provisioning side and the routing system, This document does not introduce any new security considerations; it
establishing the local view of global RPKI data to BGP speakers. The is a resource for implementers. The RP links the RPKI provisioning
security of the RP is critical to BGP messages exchanging. The RP side and the routing system, establishing a verified, local view of
implementation is expected to offer cache backup management to global RPKI data to BGP speakers. The security of the RP is critical
facilitate recovery from outage state. The RP implementation also for exchanging BGP messages. Each RP implementation is expected to
should support application of secure transport (e.g., IPsec offer cache backup management to facilitate recovery from outages.
[RFC4301]) that is able to protect validated cache delivery in a RP software should also support secure transport (e.g., IPsec
unsafe environment. [RFC4301]) that can protect validated cache delivery in 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 8. IANA Considerations
This document has no actions for IANA. This document has no IANA actions.
9. Acknowledgements
The authors thank David Mandelberg, Wei Wang, Tim Bruijnzeels, George
Michaelson and Oleg Muravskiy for their review, feedback and
editorial assistance in preparing this document.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004, DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>. <https://www.rfc-editor.org/info/rfc3779>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
skipping to change at page 10, line 20 skipping to change at line 449
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012, DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>. <https://www.rfc-editor.org/info/rfc6487>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>. <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) [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
February 2012, <https://www.rfc-editor.org/info/rfc6493>. February 2012, <https://www.rfc-editor.org/info/rfc6493>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key [RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810, Infrastructure (RPKI) to Router Protocol", RFC 6810,
DOI 10.17487/RFC6810, January 2013, DOI 10.17487/RFC6810, January 2013,
<https://www.rfc-editor.org/info/rfc6810>. <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 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for
Algorithms and Key Sizes for Use in the Resource Public Algorithms and Key Sizes for Use in the Resource Public
Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
August 2016, <https://www.rfc-editor.org/info/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 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists, BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", RFC 8209, and Certification Requests", RFC 8209,
DOI 10.17487/RFC8209, September 2017, DOI 10.17487/RFC8209, September 2017,
<https://www.rfc-editor.org/info/rfc8209>. <https://www.rfc-editor.org/info/rfc8209>.
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key [RFC8210] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 1", Infrastructure (RPKI) to Router Protocol, Version 1",
RFC 8210, DOI 10.17487/RFC8210, September 2017, RFC 8210, DOI 10.17487/RFC8210, September 2017,
<https://www.rfc-editor.org/info/rfc8210>. <https://www.rfc-editor.org/info/rfc8210>.
[RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T.,
Newton, A., and D. Shaw, "Resource Public Key Newton, A., and D. Shaw, "Resource Public Key
Infrastructure (RPKI) Validation Reconsidered", RFC 8360, Infrastructure (RPKI) Validation Reconsidered", RFC 8360,
DOI 10.17487/RFC8360, April 2018, DOI 10.17487/RFC8360, April 2018,
<https://www.rfc-editor.org/info/rfc8360>. <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. [RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630, Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630,
August 2019, <https://www.rfc-editor.org/info/rfc8630>. August 2019, <https://www.rfc-editor.org/info/rfc8630>.
10.2. Informative References [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 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/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, [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017, DOI 10.17487/RFC8182, July 2017,
<https://www.rfc-editor.org/info/rfc8182>. <https://www.rfc-editor.org/info/rfc8182>.
[RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification [RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification
Authority (CA) or Repository Manager in the Resource Authority (CA) or Repository Manager in the Resource
Public Key Infrastructure (RPKI)", RFC 8211, Public Key Infrastructure (RPKI)", RFC 8211,
DOI 10.17487/RFC8211, September 2017, DOI 10.17487/RFC8211, September 2017,
<https://www.rfc-editor.org/info/rfc8211>. <https://www.rfc-editor.org/info/rfc8211>.
[RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified [RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified
Local Internet Number Resource Management with the RPKI Local Internet Number Resource Management with the RPKI
(SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018, (SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018,
<https://www.rfc-editor.org/info/rfc8416>. <https://www.rfc-editor.org/info/rfc8416>.
[RFC8634] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router [rsync] "rsync", <http://rsync.samba.org/>.
Certificate Rollover", BCP 224, RFC 8634,
DOI 10.17487/RFC8634, August 2019,
<https://www.rfc-editor.org/info/rfc8634>.
[rsync] "rsync web page", <http://rsync.samba.org/>. Acknowledgements
The authors thank David Mandelberg, Wei Wang, Tim Bruijnzeels, George
Michaelson, and Oleg Muravskiy for their review, feedback, and
editorial assistance in preparing this document.
Authors' Addresses Authors' Addresses
Di Ma Di Ma
ZDNS ZDNS
4 South 4th St. Zhongguancun 4 South 4th St. Zhongguancun
Haidian, Beijing 100190 Haidian
Beijing, 100190
China China
Email: madi@zdns.cn Email: madi@zdns.cn
Stephen Kent Stephen Kent
Independent Independent
Email: kent@alum.mit.edu Email: kent@alum.mit.edu
 End of changes. 77 change blocks. 
255 lines changed or deleted 270 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/