Requirements for Resource Public Key Infrastructure (RPKI) Relying PartiesZDNS4 South 4th St. ZhongguancunHaidian100190BeijingChinamadi@zdns.cnIndependentkent@alum.mit.edu
Routing Area
SIDROPSdns 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
.
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
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Fetching and Caching RPKI Repository Objects
. TAL Configuration and Processing
. Locating RPKI Objects Using Authority and Subject Information Extensions
. Dealing with Key Rollover
. Dealing with Algorithm Transition
. Strategies for Efficient Cache Maintenance
. Certificate and CRL Processing
. Verifying Resource Certificate and Syntax
. Certificate Path Validation
. CRL Processing
. Processing RPKI Repository Signed Objects
. Basic Signed Object Syntax Checks
. Syntax and Validation for Each Type of Signed Object
. Manifest
. ROA
. Ghostbusters
. Verifying BGPsec Router Certificate
. How to Make Use of Manifest Data
. What To Do with Ghostbusters Information
. Distributing Validated Cache
. Local Control
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionRPKI 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 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 ObjectsRP software uses synchronization mechanisms supported by targeted
repositories (e.g., or RRDP )
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 ProcessingIn 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 .Locating RPKI Objects Using Authority and Subject Information ExtensionsThe 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. 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 and of , respectively.Dealing with Key RolloverRP 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
and .Dealing with Algorithm TransitionThe 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 .Strategies for Efficient Cache MaintenanceEach 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 provides
guidance for maintenance of a local cache.Certificate and CRL ProcessingThe RPKI makes use of X.509 certificates and CRLs, but it profiles
the standard formats described in . The
major change to the profile established in is the mandatory use of a new extension in RPKI
certificates, defined in .Verifying Resource Certificate and SyntaxCertificates in the RPKI are called resource certificates, and they
are required to conform to the profile described in . An RP is required to verify that a resource
certificate adheres to the profile established by . This means that
all extensions mandated by must be present and the value of each extension
must be within the range specified by . Moreover, any extension excluded by
must be omitted. specifies
the procedure that RP software follows when verifying extensions
described in .Certificate Path ValidationInitially, 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). 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 , 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 .CRL ProcessingThe CRL processing requirements imposed on CAs and RPs are described
in . CRLs in
the RPKI are tightly constrained; only the AuthorityKeyIdentifier
() and
CRLNumber ()
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 .Processing RPKI Repository Signed ObjectsBasic Signed Object Syntax ChecksBefore an RP can use a signed object from the RPKI repository, RP software
is required to check the signed-object syntax. 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 .Syntax and Validation for Each Type of Signed ObjectManifestTo 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 .Specific checks for a manifest are described in . 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.ROATo validate a Route Origin Authorization (ROA), RP software is
required to perform all the checks specified in as well as additional,
ROA-specific validation steps. The IP Address Delegation extension
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 .GhostbustersThe 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 .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 .Verifying BGPsec Router CertificateA BGPsec Router Certificate is a resource certificate, so it is
required to comply with .
Additionally, the certificate must contain an AS Identifier
Delegation extension () and must not contain an IP Address Delegation
extension (). The validation procedure used for BGPsec
Router Certificates is analogous to the validation procedure
described in , but it uses the constraints defined in .Note that the cryptographic algorithms used by BGPsec routers are
found in . Currently, the
algorithms specified in
and 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 DataFor a given publication point, RP software ought to perform tests,
as specified in , 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, 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 ). 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 and of ).What To Do with Ghostbusters InformationRP 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 CacheOn 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 and .Local ControlISPs 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 . 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 .Security ConsiderationsThis 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 ) 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 ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesX.509 Extensions for IP Addresses and AS IdentifiersThis document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK]Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]A Profile for Resource Certificate Repository StructureThis document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK]A Profile for Route Origin Authorizations (ROAs)This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK]Manifests for the Resource Public Key Infrastructure (RPKI)This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. [STANDARDS-TRACK]A Profile for X.509 PKIX Resource CertificatesThis document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK]Signed Object Template for the Resource Public Key Infrastructure (RPKI)This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK]Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for relying parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs. This memo documents an Internet Best Current Practice.The Resource Public Key Infrastructure (RPKI) Ghostbusters RecordIn the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate. The data in the record are those of a severely profiled vCard. [STANDARDS- TRACK]The Resource Public Key Infrastructure (RPKI) to Router ProtocolIn order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK]Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children).The Profile for Algorithms and Key Sizes for Use in the Resource Public Key InfrastructureThis document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures.A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification RequestsThis document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this document updates the RPKI Resource Certificates Profile (RFC 6487).The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them.This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810.Resource Public Key Infrastructure (RPKI) Validation ReconsideredThis document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource Public Key Infrastructure (RPKI), while retaining essential security features.The procedure specified in RFC 6487 requires that Resource Certificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing Certification Authority (CA) to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate.It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document.This choice is signaled by a set of alternative Object Identifiers (OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers" (RFC 3779) and "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487.Furthermore, this document provides an alternative to Route Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation.BGPsec Algorithms, Key Formats, and Signature FormatsThis document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Documentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading.This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.Resource Public Key Infrastructure (RPKI) Trust Anchor LocatorThis document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). The TAL allows Relying Parties in the RPKI to download the current Trust Anchor (TA) Certification Authority (CA) certificate from one or more locations and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys but can allow these TAs to change the content of their CA certificate. In particular, it allows TAs to change the set of IP Address Delegations and/or Autonomous System Identifier Delegations included in the extension(s) (RFC 3779) of their certificate.This document obsoletes the previous definition of the TAL as provided in RFC 7730 by adding support for Uniform Resource Identifiers (URIs) (RFC 3986) that use HTTP over TLS (HTTPS) (RFC 7230) as the scheme.BGPsec Router Certificate RolloverCertification Authorities (CAs) within the Resource Public Key Infrastructure (RPKI) manage BGPsec router certificates as well as RPKI certificates. The rollover of BGPsec router certificates must be carefully performed in order to synchronize the distribution of router public keys with BGPsec UPDATE messages verified with those router public keys. This document describes a safe rollover process, and it discusses when and why the rollover of BGPsec router certificates is necessary. When this rollover process is followed, the rollover will be performed without routing information being lost.Informative ReferencesSecurity Architecture for the Internet ProtocolThis document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]An Infrastructure to Support Secure Internet RoutingThis document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.The RPKI Repository Delta Protocol (RRDP)In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files.Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)This document analyzes actions by or against a Certification Authority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by Relying Parties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data.Simplified Local Internet Number Resource Management with the RPKI (SLURM)The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions. ISPs can also use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed.rsyncAcknowledgementsThe authors thank , , , , and
for their review, feedback, and editorial assistance in preparing this
document.Authors' AddressesZDNS4 South 4th St. ZhongguancunHaidian100190BeijingChinamadi@zdns.cnIndependentkent@alum.mit.edu