Difference between revisions of "RFC8897"
| Line 30: | Line 30: | ||
Internet Engineering Steering Group (IESG). Not all documents | Internet Engineering Steering Group (IESG). Not all documents | ||
approved by the IESG are candidates for any level of Internet | approved by the IESG are candidates for any level of Internet | ||
| − | Standard; see Section 2 of | + | Standard; see Section 2 of RFC 7841. |
Information about the current status of this document, any errata, | Information about the current status of this document, any errata, | ||
| Line 41: | Line 41: | ||
document authors. All rights reserved. | document authors. All rights reserved. | ||
| − | This document is subject to | + | 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 | ||
| Line 94: | Line 94: | ||
The essential requirements imposed on RP software to support secure | The essential requirements imposed on RP software to support secure | ||
| − | Internet routing [[RFC6480]] are scattered throughout numerous | + | Internet routing [[[RFC6480]]] are scattered throughout numerous |
protocol-specific RFCs and Best Current Practice RFCs. The following | protocol-specific RFCs and Best Current Practice RFCs. The following | ||
RFCs define these requirements: | RFCs define these requirements: | ||
| − | + | RFC 6481 (Repository Structure) | |
| − | + | RFC 6482 (ROA format) | |
| − | + | RFC 6486 (Manifests) | |
| − | + | RFC 6487 (Certificate and CRL profile) | |
| − | + | RFC 6488 (RPKI Signed Objects) | |
| − | + | RFC 6489 (Key Rollover) | |
| − | + | RFC 6810 (RPKI to Router Protocol) | |
| − | + | RFC 6916 (Algorithm Agility) | |
| − | + | RFC 7935 (Algorithms) | |
| − | + | RFC 8209 (Router Certificates) | |
| − | + | RFC 8210 (RPKI to Router Protocol, Version 1) | |
| − | + | RFC 8360 (Certificate Validation Procedure) | |
| − | + | RFC 8630 (Trust Anchor Locator) | |
The distribution of RPKI RP requirements across these 13 documents | The distribution of RPKI RP requirements across these 13 documents | ||
| Line 140: | Line 140: | ||
RP software uses synchronization mechanisms supported by targeted | RP software uses synchronization mechanisms supported by targeted | ||
| − | repositories (e.g., [rsync] or RRDP [[RFC8182]]) to download RPKI | + | repositories (e.g., [rsync] or RRDP [[[RFC8182]]]) to download RPKI |
signed objects from the repository system in order to update a local | signed objects from the repository system in order to update a local | ||
cache. These mechanisms download only those objects that have been | cache. These mechanisms download only those objects that have been | ||
| Line 161: | Line 161: | ||
TAL configuration and processing are specified in Section 3 of | TAL configuration and processing are specified in Section 3 of | ||
| − | [[RFC8630]]. | + | [[[RFC8630]]]. |
=== Locating RPKI Objects Using Authority and Subject Information === | === Locating RPKI Objects Using Authority and Subject Information === | ||
| Line 173: | Line 173: | ||
certificates. | certificates. | ||
| − | Section 5 of [[RFC6481]] specifies how RP software locates all RPKI | + | Section 5 of [[[RFC6481]]] specifies how RP software locates all RPKI |
objects by using the SIA and AIA extensions. Detailed specifications | objects by using the SIA and AIA extensions. Detailed specifications | ||
of SIA and AIA extensions in a resource certificate are described in | of SIA and AIA extensions in a resource certificate are described in | ||
| − | Sections 4.8.8 and 4.8.7 of [[RFC6487]], respectively. | + | Sections 4.8.8 and 4.8.7 of [[[RFC6487]]], respectively. |
=== Dealing with Key Rollover === | === Dealing with Key Rollover === | ||
| Line 184: | Line 184: | ||
RP software requirements for dealing with key rollover are described | RP software requirements for dealing with key rollover are described | ||
| − | in Section 3 of [[RFC6489]] and Section 3 of [[RFC8634]]. | + | in Section 3 of [[[RFC6489]]] and Section 3 of [[[RFC8634]]]. |
=== Dealing with Algorithm Transition === | === Dealing with Algorithm Transition === | ||
| Line 194: | Line 194: | ||
RP software requirements for dealing with algorithm transition are | RP software requirements for dealing with algorithm transition are | ||
| − | specified in Section 4 of [[RFC6916]]. | + | specified in Section 4 of [[[RFC6916]]]. |
=== Strategies for Efficient Cache Maintenance === | === Strategies for Efficient Cache Maintenance === | ||
| Line 204: | Line 204: | ||
constraints. | 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. | ||
| Line 210: | Line 210: | ||
The RPKI makes use of X.509 certificates and CRLs, but it profiles | The RPKI makes use of X.509 certificates and CRLs, but it profiles | ||
| − | the standard formats described in [[RFC6487]]. The major change to the | + | the standard formats described in [[[RFC6487]]]. The major change to the |
| − | profile established in [[RFC5280]] is the mandatory use of a new | + | profile established in [[[RFC5280]]] is the mandatory use of a new |
| − | extension in RPKI certificates, defined in [[RFC3779]]. | + | extension in RPKI certificates, defined in [[[RFC3779]]]. |
=== Verifying Resource Certificate and Syntax === | === 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 described in [[RFC6487]]. An RP | + | are required to conform to the profile described in [[[RFC6487]]]. An RP |
is required to verify that a resource certificate adheres to the | is required to verify that a resource certificate adheres to the | ||
| − | profile 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 |
the value of each extension must be within the range specified by | the value of each extension must be within the range specified by | ||
| − | [[RFC6487]]. Moreover, any extension excluded by Section 4.8 of | + | [[[RFC6487]]]. Moreover, any extension excluded by Section 4.8 of |
| − | [[RFC6487]] must be omitted. | + | [[[RFC6487]]] must be omitted. |
| − | Section 7.1 of [[RFC6487]] specifies the procedure that RP software | + | Section 7.1 of [[[RFC6487]]] specifies the procedure that RP software |
| − | follows when verifying extensions described in [[RFC3779]]. | + | follows when verifying extensions described in [[[RFC3779]]]. |
=== Certificate Path Validation === | === Certificate Path Validation === | ||
| Line 236: | Line 236: | ||
each certificate using the public key of the parent certificate). | each certificate using the public key of the parent certificate). | ||
| − | Section 7.2 of [[RFC6487]] specifies the procedure that RP software | + | Section 7.2 of [[[RFC6487]]] specifies the procedure that RP software |
should follow to perform certificate path validation. | should follow to perform certificate path validation. | ||
Certification Authorities (CAs) that want to reduce aspects of | Certification Authorities (CAs) that want to reduce aspects of | ||
| − | operational fragility will migrate to the new OIDs [[RFC8360]], | + | operational fragility will migrate to the new OIDs [[[RFC8360]]], |
informing RP software to use an alternative RPKI validation | informing RP software to use an alternative RPKI validation | ||
algorithm. An RP is expected to support the amended procedure to | algorithm. An RP is expected to support the amended procedure to | ||
handle accidental overclaiming, which is described in Section 4 of | handle accidental overclaiming, which is described in Section 4 of | ||
| − | [[RFC8360]]. | + | [[[RFC8360]]]. |
=== CRL Processing === | === CRL Processing === | ||
The CRL processing requirements imposed on CAs and RPs 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 AuthorityKeyIdentifier (Section 4.8.3 of [[RFC6487]]) and | + | only the AuthorityKeyIdentifier (Section 4.8.3 of [[[RFC6487]]]) and |
| − | CRLNumber (Section 5.2.3 of [[RFC5280]]) extensions are allowed, and | + | CRLNumber (Section 5.2.3 of [[[RFC5280]]]) extensions are allowed, and |
they are required to be present. No other CRL extensions are | they are required to be present. No other CRL extensions are | ||
allowed, and no CRLEntry extensions are permitted. RP software is | allowed, and no CRLEntry extensions are permitted. RP software is | ||
| Line 264: | Line 264: | ||
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 fifth paragraph of | matter of local policy, as described in the fifth paragraph of | ||
| − | Section 6.6 of [[RFC6486]]. | + | Section 6.6 of [[[RFC6486]]]. |
== Processing RPKI Repository Signed Objects == | == Processing RPKI Repository Signed Objects == | ||
| Line 273: | Line 273: | ||
software 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 RP software is | + | Section 3 of [[[RFC6488]]] lists all the steps that RP software is |
required to execute in order to validate the top-level syntax of a | required to execute in order to validate the top-level syntax of a | ||
repository signed object. | repository signed object. | ||
| Line 287: | Line 287: | ||
To determine whether a manifest is valid, RP software is required to | To determine whether a manifest is valid, RP software is required to | ||
perform manifest-specific checks in addition to the generic signed- | perform manifest-specific checks in addition to the generic signed- | ||
| − | object checks specified in [[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 fail, indicating that the manifest | + | [[[RFC6486]]]. If any of these checks fail, indicating that the manifest |
is invalid, then the manifest will be discarded, and RP software will | is invalid, then the manifest will be discarded, and RP software will | ||
act as though no manifest were present. | act as though no manifest were present. | ||
| Line 297: | Line 297: | ||
To validate a Route Origin Authorization (ROA), RP software is | To validate a Route Origin Authorization (ROA), RP software is | ||
| − | required to perform all the checks specified in [[RFC6488]] as well as | + | required to perform all the checks specified in [[[RFC6488]]] as well as |
additional, ROA-specific validation steps. The IP Address Delegation | additional, ROA-specific validation steps. The IP Address Delegation | ||
| − | extension [[RFC3779]] present in the end-entity (EE) certificate | + | extension [[[RFC3779]]] present in the end-entity (EE) certificate |
(contained within the ROA) must encompass each of the IP address | (contained within the ROA) must encompass each of the IP address | ||
prefix(es) in the ROA. | 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]]]. |
==== Ghostbusters ==== | ==== Ghostbusters ==== | ||
| Line 312: | Line 312: | ||
at least one Ghostbusters Record, RP software is required to verify | at least one Ghostbusters Record, RP software is required to verify | ||
that this Ghostbusters Record conforms to the syntax of signed | that this Ghostbusters Record conforms to the syntax of signed | ||
| − | objects defined in [[RFC6488]]. | + | objects defined in [[[RFC6488]]]. |
The payload of this signed object is a (severely) profiled vCard. RP | The payload of this signed object is a (severely) profiled vCard. RP | ||
software is required to verify that the payload of Ghostbusters | software is required to verify that the payload of Ghostbusters | ||
| − | conforms to format as profiled in [[RFC6493]]. | + | conforms to format as profiled in [[[RFC6493]]]. |
==== Verifying BGPsec Router Certificate ==== | ==== 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 (Section 4.8.11 of | must contain an AS Identifier Delegation extension (Section 4.8.11 of | ||
| − | [[RFC6487]]) and must not contain an IP Address Delegation extension | + | [[[RFC6487]]]) and must not contain an IP Address Delegation extension |
| − | (Section 4.8.10 of [[RFC6487]]). The validation procedure used for | + | (Section 4.8.10 of [[[RFC6487]]]). The validation procedure used for |
BGPsec Router Certificates is analogous to the validation procedure | BGPsec Router Certificates is analogous to the validation procedure | ||
| − | described in Section 7 of [[RFC6487]], but it uses the constraints | + | described in Section 7 of [[[RFC6487]]], but it uses the constraints |
| − | defined in Section 3 of [[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 [[RFC8608]]. Currently, the algorithms specified in [[RFC8608]] | + | found in [[[RFC8608]]]. Currently, the algorithms specified in [[[RFC8608]]] |
| − | and [[RFC7935]] are different. BGPsec RP software will need to support | + | and [[[RFC7935]]] are different. BGPsec RP software will need to support |
algorithms that are used to validate BGPsec signatures as well as the | algorithms that are used to validate BGPsec signatures as well as the | ||
algorithms that are needed to validate signatures on BGPsec | algorithms that are needed to validate signatures on BGPsec | ||
| Line 339: | Line 339: | ||
For a given publication point, RP software 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 or | either valid or invalid, and a valid manifest is either current or | ||
| Line 346: | Line 346: | ||
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. | behavior with respect to such objects. | ||
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 (see Section 6.2 of | signed objects present in the publication point (see Section 6.2 of | ||
| − | [[RFC6486]]). If a manifest is stale or invalid and an RP has no way | + | [[[RFC6486]]]). If a manifest is stale or invalid and an RP has no way |
to acquire a more recent valid manifest, the RP is expected to | to acquire a more recent valid manifest, the RP is expected to | ||
contact the repository manager via Ghostbusters Records and | contact the repository manager via Ghostbusters Records and | ||
thereafter make decisions according to local (RP) policy (see | thereafter make decisions according to local (RP) policy (see | ||
| − | Sections 6.3 and 6.4 of [[RFC6486]]). | + | Sections 6.3 and 6.4 of [[[RFC6486]]]). |
=== What To Do with Ghostbusters Information === | === What To Do with Ghostbusters Information === | ||
| Line 375: | Line 375: | ||
such data to BGP speakers. The specifications of the protocol | such data to BGP speakers. The specifications of the protocol | ||
designed to deliver validated cache data to a BGP Speaker are | designed to deliver validated cache data to a BGP Speaker are | ||
| − | provided in [[RFC6810]] and [[RFC8210]]. | + | provided in [[[RFC6810]]] and [[[RFC8210]]]. |
== Local Control == | == Local Control == | ||
| Line 382: | Line 382: | ||
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]]]. |
== Security Considerations == | == Security Considerations == | ||
| Line 397: | Line 397: | ||
offer cache backup management to facilitate recovery from outages. | offer cache backup management to facilitate recovery from outages. | ||
RP software should also support secure transport (e.g., IPsec | RP software should also support secure transport (e.g., IPsec | ||
| − | [[RFC4301]]) that can protect validated cache delivery in an unsafe | + | [[[RFC4301]]]) that can protect validated cache delivery in an unsafe |
environment. This document highlights many validation actions | environment. This document highlights many validation actions | ||
applied to RPKI signed objects, an essential element of secure | applied to RPKI signed objects, an essential element of secure | ||
| Line 410: | Line 410: | ||
=== Normative References === | === 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", | + | 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", | + | (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, |
<https://www.rfc-editor.org/info/rfc5280>. | <https://www.rfc-editor.org/info/rfc5280>. | ||
| − | [[RFC6481]] Huston, G., Loomans, R., and G. Michaelson, "A Profile for | + | [[[RFC6481]]] Huston, G., Loomans, R., and G. Michaelson, "A Profile for |
| − | Resource Certificate Repository Structure", | + | Resource Certificate Repository Structure", RFC 6481, |
DOI 10.17487/RFC6481, February 2012, | DOI 10.17487/RFC6481, February 2012, | ||
<https://www.rfc-editor.org/info/rfc6481>. | <https://www.rfc-editor.org/info/rfc6481>. | ||
| − | [[RFC6482]] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route | + | [[[RFC6482]]] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route |
| − | Origin Authorizations (ROAs)", | + | Origin Authorizations (ROAs)", RFC 6482, |
DOI 10.17487/RFC6482, February 2012, | DOI 10.17487/RFC6482, February 2012, | ||
<https://www.rfc-editor.org/info/rfc6482>. | <https://www.rfc-editor.org/info/rfc6482>. | ||
| − | [[RFC6486]] Austein, R., Huston, G., Kent, S., and M. Lepinski, | + | [[[RFC6486]]] Austein, R., Huston, G., Kent, S., and M. Lepinski, |
"Manifests for the Resource Public Key Infrastructure | "Manifests for the Resource Public Key Infrastructure | ||
| − | (RPKI)", | + | (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, |
<https://www.rfc-editor.org/info/rfc6486>. | <https://www.rfc-editor.org/info/rfc6486>. | ||
| − | [[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", | + | 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)", | + | (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 | + | [[[RFC6489]]] Huston, G., Michaelson, G., and S. Kent, "Certification |
Authority (CA) Key Rollover in the Resource Public Key | Authority (CA) Key Rollover in the Resource Public Key | ||
| − | Infrastructure (RPKI)", | + | Infrastructure (RPKI)", BCP 174, RFC 6489, |
DOI 10.17487/RFC6489, February 2012, | DOI 10.17487/RFC6489, February 2012, | ||
<https://www.rfc-editor.org/info/rfc6489>. | <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", | + | 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", | + | 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 | + | [[[RFC6916]]] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility |
Procedure for the Resource Public Key Infrastructure | Procedure for the Resource Public Key Infrastructure | ||
| − | (RPKI)", | + | (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April |
2013, <https://www.rfc-editor.org/info/rfc6916>. | 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", | + | 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>. | ||
| − | [[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", | + | 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, | |
<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", | + | 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 | + | [[[RFC8608]]] Turner, S. and O. Borchert, "BGPsec Algorithms, Key |
| − | Formats, and Signature Formats", | + | Formats, and Signature Formats", RFC 8608, |
DOI 10.17487/RFC8608, June 2019, | DOI 10.17487/RFC8608, June 2019, | ||
<https://www.rfc-editor.org/info/rfc8608>. | <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", | + | 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>. | ||
| − | [[RFC8634]] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router | + | [[[RFC8634]]] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router |
| − | Certificate Rollover", | + | Certificate Rollover", BCP 224, RFC 8634, |
DOI 10.17487/RFC8634, August 2019, | DOI 10.17487/RFC8634, August 2019, | ||
<https://www.rfc-editor.org/info/rfc8634>. | <https://www.rfc-editor.org/info/rfc8634>. | ||
| Line 505: | Line 505: | ||
=== Informative References === | === Informative References === | ||
| − | [[RFC4301]] Kent, S. and K. Seo, "Security Architecture for the | + | [[[RFC4301]]] Kent, S. and K. Seo, "Security Architecture for the |
| − | Internet Protocol", | + | 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", | + | 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>. | ||
| − | [[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)", | + | "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)", | + | 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)", | + | (SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018, |
<https://www.rfc-editor.org/info/rfc8416>. | <https://www.rfc-editor.org/info/rfc8416>. | ||
Revision as of 10:40, 25 October 2020
Internet Engineering Task Force (IETF) D. Ma Request for Comments: 8897 ZDNS Category: Informational S. Kent ISSN: 2070-1721 Independent
September 2020
Requirements for Resource Public Key Infrastructure (RPKI) Relying
Parties
Abstract
This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI). It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements. Over time, this RFC will be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the 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.
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 (c) 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.
1. Introduction 2. Fetching and Caching RPKI Repository Objects
2.1. TAL Configuration and Processing
2.2. Locating RPKI Objects Using Authority and Subject
Information Extensions
2.3. Dealing with Key Rollover
2.4. Dealing with Algorithm Transition
2.5. Strategies for Efficient Cache Maintenance
3. Certificate and CRL Processing
3.1. Verifying Resource Certificate and Syntax 3.2. Certificate Path Validation 3.3. CRL Processing
4. Processing RPKI Repository Signed Objects
4.1. Basic Signed Object Syntax Checks 4.2. Syntax and Validation for Each Type of Signed Object 4.2.1. Manifest 4.2.2. ROA 4.2.3. Ghostbusters 4.2.4. Verifying BGPsec Router Certificate 4.3. How to Make Use of Manifest Data 4.4. What To Do with Ghostbusters Information
5. Distributing Validated Cache 6. Local Control 7. Security Considerations 8. IANA Considerations 9. References
9.1. Normative References 9.2. Informative References
Acknowledgements Authors' Addresses
Contents
Introduction
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, 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 and indicates the AS numbers that each router is authorized to represent.
The essential requirements imposed on RP software to support secure Internet routing [[[RFC6480]]] are scattered throughout numerous protocol-specific RFCs and Best Current Practice RFCs. The following RFCs define these requirements:
RFC 6481 (Repository Structure) RFC 6482 (ROA format) RFC 6486 (Manifests) RFC 6487 (Certificate and CRL profile) RFC 6488 (RPKI Signed Objects) RFC 6489 (Key Rollover) RFC 6810 (RPKI to Router Protocol) RFC 6916 (Algorithm Agility) RFC 7935 (Algorithms) RFC 8209 (Router Certificates) RFC 8210 (RPKI to Router Protocol, Version 1) RFC 8360 (Certificate Validation Procedure) RFC 8630 (Trust Anchor Locator)
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 requirements. Additionally, good software engineering practice may call for segmenting the RP system into components with orthogonal functionalities so that those components may be distributed. A taxonomy of the collected RP software requirements can help clarify the role of the 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. The requirements are organized into four groups:
- Fetching and Caching RPKI Repository Objects
- Processing Certificates and Certificate Revocation Lists (CRLs)
- 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.
Fetching and Caching RPKI Repository Objects
RP software uses synchronization mechanisms supported by targeted repositories (e.g., [rsync] or RRDP [[[RFC8182]]]) to download RPKI signed objects from the repository system 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 and which routers are authorized to sign BGP updates on behalf of specified ASes.
TAL Configuration and Processing
In the RPKI, each RP chooses a set of trust anchors (TAs). Consistent with the extant INR allocation hierarchy, the IANA and/or 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 (TALs) is used by RP software to retrieve and verify the authenticity of each TA.
TAL configuration and processing are specified in Section 3 of [[[RFC8630]]].
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. 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 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 Sections 4.8.8 and 4.8.7 of [[[RFC6487]]], respectively.
Dealing with Key Rollover
RP software takes the key rollover period into account with regard to its frequency of synchronization with the RPKI repository system.
RP software requirements for dealing with key rollover are described in Section 3 of [[[RFC6489]]] and Section 3 of [[[RFC8634]]].
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]]].
Strategies for Efficient Cache Maintenance
Each RP is expected to maintain a local cache of RPKI objects. The cache needs to be brought up to date and made consistent with the 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 maintenance of a local cache.
Certificate and CRL Processing
The RPKI makes use of X.509 certificates and CRLs, but it profiles the standard formats described in [[[RFC6487]]]. The major change to the profile established in [[[RFC5280]]] is the mandatory use of a new extension in RPKI certificates, defined in [[[RFC3779]]].
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 [[[RFC6487]]]. Moreover, any extension excluded by Section 4.8 of [[[RFC6487]]] must be omitted.
Section 7.1 of [[[RFC6487]]] specifies the procedure that RP software follows when verifying extensions described in [[[RFC3779]]].
Certificate Path Validation
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., verification of the signature on each certificate using the public key of the parent certificate).
Section 7.2 of [[[RFC6487]]] specifies the procedure that RP software should follow to perform certificate path validation.
Certification Authorities (CAs) that want to reduce aspects of operational fragility will migrate to the new OIDs [[[RFC8360]]], informing RP software to use an alternative RPKI validation algorithm. An RP is expected to support the amended procedure to handle accidental overclaiming, which is described in Section 4 of [[[RFC8360]]].
CRL Processing
The CRL processing requirements imposed on CAs and RPs are described in Section 5 of [[[RFC6487]]]. CRLs in the RPKI are tightly constrained; only the AuthorityKeyIdentifier (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. 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 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 fifth paragraph of Section 6.6 of [[[RFC6486]]].
Processing RPKI Repository Signed Objects
Basic Signed Object Syntax Checks
Before an RP can use a signed object from the RPKI repository, RP software is required to check the signed-object syntax.
Section 3 of [[[RFC6488]]] lists all the steps that RP software is required to execute in order to validate the top-level syntax of a repository signed object.
Note that these checks are necessary but not sufficient. Additional validation checks must be performed based on the specific type of signed object, as described in Section 4.2.
Syntax and Validation for Each Type of Signed Object
Manifest
To determine whether a manifest is valid, RP software is required to perform manifest-specific checks in addition to the generic signed- object checks specified in [[[RFC6488]]].
Specific checks for a manifest are described in Section 4 of [[[RFC6486]]]. If any of these checks fail, indicating that the manifest is invalid, then the manifest will be discarded, and RP software will act as though no manifest were present.
ROA
To validate a Route Origin Authorization (ROA), RP software is required to perform all the checks specified in [[[RFC6488]]] as well as additional, ROA-specific validation steps. The IP Address Delegation extension [[[RFC3779]]] present in the end-entity (EE) certificate (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 [[[RFC6482]]].
Ghostbusters
The Ghostbusters Record is optional; a publication point in the RPKI can have zero or more associated Ghostbusters Records. If a CA has at least one Ghostbusters Record, RP software is required to verify that this Ghostbusters Record conforms to the syntax of signed objects defined in [[[RFC6488]]].
The payload of this signed object is a (severely) profiled vCard. RP software is required to verify that the payload of Ghostbusters conforms to format as profiled in [[[RFC6493]]].
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 (Section 4.8.11 of [[[RFC6487]]]) and must not contain an IP Address Delegation extension (Section 4.8.10 of [[[RFC6487]]]). The validation procedure used for BGPsec Router Certificates is analogous to the validation procedure described in Section 7 of [[[RFC6487]]], but it uses the constraints defined in Section 3 of [[[RFC8209]]].
Note that the cryptographic algorithms used by BGPsec routers are found in [[[RFC8608]]]. Currently, the algorithms specified in [[[RFC8608]]] and [[[RFC7935]]] are different. BGPsec 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.
How to Make Use of Manifest Data
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 manifest at the publication point. A manifest can be classified as 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 state, according to local (RP) policy.
If there are valid objects in a publication point that are not present on a manifest, [[[RFC6486]]] does not mandate specific RP behavior with respect to such objects.
In the absence of a manifest, an RP is expected to accept all valid signed objects present in the publication point (see Section 6.2 of [[[RFC6486]]]). If a manifest is stale or invalid and an RP has no way to acquire a more recent valid manifest, the RP is expected to contact the repository manager via Ghostbusters Records and thereafter make decisions according to local (RP) policy (see Sections 6.3 and 6.4 of [[[RFC6486]]]).
What To Do with Ghostbusters Information
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 the information from the Ghostbusters 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 stale or expired objects.
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 specifications of the protocol designed to deliver validated cache data to a BGP Speaker are provided in [[[RFC6810]]] and [[[RFC8210]]].
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]]]. The mechanisms developed to provide this capability to network operators are called 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]]].
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 a verified, local view of global RPKI data to BGP speakers. The security of the RP is critical for exchanging BGP messages. Each RP implementation is expected to offer cache backup management to facilitate recovery from outages. RP software should also support secure transport (e.g., IPsec [[[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.
IANA Considerations
This document has no IANA actions.
References
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>.
[[[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>.
[[[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>.
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>.
[[[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>.
[rsync] "rsync", <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
Di Ma ZDNS 4 South 4th St. Zhongguancun Haidian Beijing, 100190 China
Email: [email protected]
Stephen Kent Independent
Email: [email protected]
