SIDROPS D. Ma Internet-Draft ZDNS Intended status: Informational S. Kent Expires: August 1, 2019 Independent January 28, 2019 Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties draft-ietf-sidrops-rp-03 Abstract This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI) in the context of securing Internet routing. It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements that are segmented with orthogonal functionalities. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 1, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Ma & Kent Expires August 1, 2019 [Page 1] Internet-Draft RPKI RP Requirements January 2019 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Fetching and Caching RPKI Repository Objects . . . . . . . . 3 2.1. TAL Acquisition and Processing . . . . . . . . . . . . . 4 2.2. Locating RPKI Objects Using Authority and Subject Information Extensions . . . . . . . . . . . . . . . . . 4 2.3. Dealing with Key Rollover . . . . . . . . . . . . . . . . 4 2.4. Dealing with Algorithm Transition . . . . . . . . . . . . 4 2.5. Strategies for Efficient Cache Maintenance . . . . . . . 5 3. Certificate and CRL Processing . . . . . . . . . . . . . . . 5 3.1. Verifying Resource Certificate and Syntax . . . . . . . . 5 3.2. Certificate Path Validation . . . . . . . . . . . . . . . 5 3.3. CRL Processing . . . . . . . . . . . . . . . . . . . . . 6 4. Processing RPKI Repository Signed Objects . . . . . . . . . . 6 4.1. Basic Signed Object Syntax Checks . . . . . . . . . . . . 6 4.2. Syntax and Validation for Each Type of Signed Object . . 6 4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. ROA . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.3. Ghostbusters . . . . . . . . . . . . . . . . . . . . 7 4.2.4. Verifying BGPsec Router Certificate . . . . . . . . . 7 4.3. How to Make Use of Manifest Data . . . . . . . . . . . . 7 4.4. What to Do with Ghostbusters Information . . . . . . . . 8 5. Distributing Validated Cache . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The RPKI Relying Party (RP) software is used by network operators and others to acquire and verify Internet Number Resource (INR) data stored in the RPKI repository system. RPKI data, when verified, allow an RP to verify assertions about which Autonomous Systems (ASes) are authorized to originate routes for IP address prefixes. RPKI data also establishes binding between public keys and BGP routers, and indicates the AS numbers that each router is authorized to represent. Ma & Kent Expires August 1, 2019 [Page 2] Internet-Draft RPKI RP Requirements January 2019 Noting that the essential requirements imposed on RPs to support securing Internet routing ([RFC6480]) are scattered throughout numerous RFC documents that are protocol specific or provide best practices, as follows: 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) I-D.ietf-sidrops-https-tal (Trust Anchor Locator) This makes it hard for an implementer to be confident that he/she has addressed all of these generalized requirements. Besides, software engineering calls for how to segment the RP system into components with orthogonal functionalities, so that those components could be distributed across the operational timeline of the user. Taxonomy of generalized RP requirements is going to help have 'the role of the RP' well framed. To consolidate RP requirements in one document, with pointers to all the relevant RFCs, this document outlines a set of baseline requirements imposed on RPs and provides a single reference point for requirements for RP software for use in the RPKI, as segmented with orthogonal functionalities: o 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 as these RFCs are updated, or new RFCs are written. 2. Fetching and Caching RPKI Repository Objects RP software uses synchronization mechanisms supported by targeted repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI changed data objects in the repository system and cache them locally. The software validates the RPKI data and uses it to generate authenticated data identifying which ASes are authorized to originate Ma & Kent Expires August 1, 2019 [Page 3] Internet-Draft RPKI RP Requirements January 2019 routes for address prefixes, and which routers are authorized to sign BGP updates on behalf of ASes. 2.1. TAL Acquisition and Processing In the RPKI, each RP chooses its own set of trust anchors (TAs). Consistent with the extant INR allocation hierarchy, the IANA and/or the five RIRs are obvious candidates to be default TAs for the RP. An RP does not retrieve TAs directly. A set of Trust Anchor Locators (TALs) is used by each RP to retrieve and verify the authenticity of each TA. TAL acquisition and processing are specified in Section 3 of [I-D.ietf-sidrops-https-tal]. 2.2. Locating RPKI Objects Using Authority and Subject Information Extensions The RPKI repository system is a distributed one, consisting of multiple repository instances. Each repository instance contains one or more repository publication points. An RP discovers publication points using the Subject Information Access (SIA) and the Authority Information Access (AIA) extensions from (validated) certificates. Section 5 of [RFC6481] specifies how an RP locates all RPKI objects by using the SIA and AIA extensions. Detailed specifications of SIA and AIA extensions in a resource certificate are described in Section 4 of [RFC6487]. 2.3. Dealing with Key Rollover An RP takes the key rollover period into account with regard to its frequency of synchronization with RPKI repository system. RP requirements in dealing with key rollover are described in Section 3 of [RFC6489] and Section 3 of [I-D.ietf-sidrops-bgpsec-rollover]. 2.4. Dealing with Algorithm Transition The set of cryptographic algorithms used with the RPKI is expected to change over time. Each RP is expected to be aware of the milestones established for the algorithm transition and what actions are required at every juncture. RP requirements for dealing with algorithm transition are specified in Section 4 of [RFC6916]. Ma & Kent Expires August 1, 2019 [Page 4] Internet-Draft RPKI RP Requirements January 2019 2.5. Strategies for Efficient Cache Maintenance Each RP is expected to maintain a local cache of RPKI objects. The cache needs to be as up to date and consistent with repository publication point data as the RP's frequency of checking permits. The last paragraph of Section 5 of [RFC6481] provides guidance for maintenance of a local cache. 3. Certificate and CRL Processing The RPKI make use of X.509 certificates and CRLs, but it profiles these standard formats [RFC6487]. The major change to the profile established in [RFC5280] is the mandatory use of a new extension to X.509 certificate [RFC3779]. 3.1. Verifying Resource Certificate and Syntax Certificates in the RPKI are called resource certificates, and they are required to conform to the profile [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 value of each extension must be within the range specified by this RFC. Moreover, any extension excluded by Section 4.8 of [RFC6487] must be omitted. Section 7.1 of [RFC6487] gives the procedure that the RP should follow to verify resource certificate and syntax. 3.2. Certificate Path Validation In the RPKI, issuer can only assign and/or allocate public INRs belong to it, thus the INRs in issuer's certificate are required to encompass the INRs in the subject's certificate. This is one of 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] gives the procedure that the RP should follow to perform certificate path validation. Certificate Authorities that want to reduce aspects of operational fragility will migrate to the new OIDs [RFC8360], informing the RP of using an alternative RPKI validation algorithm. An RP is expected to support the amended procedure to handle with accidental over-claim. Ma & Kent Expires August 1, 2019 [Page 5] Internet-Draft RPKI RP Requirements January 2019 3.3. CRL Processing The CRL processing requirements imposed on CAs and RP are described in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained; only the AuthorityKeyIndetifier and CRLNumber extensions are allowed, and they MUST be present. No other CRL extensions are allowed, and no CRLEntry extensions are permitted. RPs are 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 fourth paragraph of Section 6.6 of [RFC6486]. 4. Processing RPKI Repository Signed Objects 4.1. Basic Signed Object Syntax Checks Before an RP can use a signed object from the RPKI repository, the RP is required to check the signed object syntax. Section 3 of [RFC6488] lists all the steps that the RP 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. 4.2. Syntax and Validation for Each Type of Signed Object 4.2.1. Manifest To determine whether a manifest is valid, the RP is required to perform manifest-specific checks in addition to those specified in [RFC6488]. Specific checks for a Manifest are described in Section 4 of [RFC6486]. If any of these checks fails, indicating that the manifest is invalid, then the manifest will be discarded and treated as though no manifest were present. Ma & Kent Expires August 1, 2019 [Page 6] Internet-Draft RPKI RP Requirements January 2019 4.2.2. ROA To validate a ROA, the RP is required perform all the checks specified in [RFC6488] as well as the 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 2 of [RFC6482]. 4.2.3. Ghostbusters The Ghostbusters Record is optional; a publication point in the RPKI can have zero or more associated Ghostbuster Records. If a CA has at least one Ghostbuster Record, RP is required to verify that this Ghostbusters Record conforms to the syntax of signed object defined in [RFC6488]. The payload of this signed object is a (severely) profiled vCard. An RP is required to verify that the payload of Ghostbusters conforms to format as profiled in [RFC6493]. 4.2.4. Verifying BGPsec Router Certificate A BGPsec Router Certificate is a resource certificate, so it is required to comply with [RFC6487]. Additionally, the certificate must contain an AS Identifier Delegation extension, and must not contain an IP Address Delegation extension. The validation procedure used for BGPsec Router Certificates is identical to the validation procedure described in Section 7 of [RFC6487], but using the constraints applied come from specification of Section 7 of [RFC8209]. Note that the cryptographic algorithms used by BGPsec routers are found in [RFC8208]. Currently, the algorithms specified in [RFC8208]and [RFC7935] are different. BGPsec RPs will need to support algorithms that are used to validate BGPsec signatures as well as the algorithms that are needed to validate signatures on BGPsec certificates, RPKI CA certificates, and RPKI CRLs. 4.3. How to Make Use of Manifest Data For a given publication point, the RP 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 and Ma & Kent Expires August 1, 2019 [Page 7] Internet-Draft RPKI RP Requirements January 2019 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. However, most RP software ignores such objects and this document recommends that this behavior be adopted uniformly. 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 stale or invalid (see [RFC6486]) and an RP has no way to acquire a more recently valid Manifest, the RP is expected to contact the repository manager via Ghostbusters record and thereafter make decision according to local (RP) policy. 4.4. What to Do with Ghostbusters Information An RP 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 record to contact the maintainer of the publication point where any stale/expired objects were encountered. The intent here is to encourage the relevant CA and/or repository manager to update the slate or expired objects. 5. Distributing Validated Cache On a periodic basis, BGP speakers within an AS request updated validated origin AS data and router/ASN data from the validated cache of RPKI data. The RP may either transfer the validated data to the BGP speakers directly, or it may transfer the validated data to a cache server that is responsible for provisioning such data to BGP speakers. The specification of the protocol designed to deliver validated cache data to a BGP Speaker is provided in [RFC6810] and [RFC8210]. 6. Security Considerations The RP links the RPKI provisioning side and the routing system, establishing the local view of global RPKI data to BGP speakers. The security of the RP is critical to BGP messages exchanging. The RP implementation is expected to offer cache backup management to facilitate recovery from outage state. The RP implementation also should support application of secure transport (e.g., IPsec [RFC4301]) that is able to protect validated cache delivery in a unsafe environment. Ma & Kent Expires August 1, 2019 [Page 8] Internet-Draft RPKI RP Requirements January 2019 7. IANA Considerations This document has no actions for IANA. 8. Acknowledgements The authors thank David Mandelberg, Wei Wang and Tim Bruijnzeels for their review, feedback and editorial assistance in preparing this document. 9. References 9.1. Normative References [I-D.ietf-sidrops-https-tal] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", draft-ietf-sidrops-https-tal-06 (work in progress), January 2019. [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, . [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, . [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, . [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, . [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, . Ma & Kent Expires August 1, 2019 [Page 9] Internet-Draft RPKI RP Requirements January 2019 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [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, . [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, . [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, . [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, . [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, . [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, . [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, . [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, . Ma & Kent Expires August 1, 2019 [Page 10] Internet-Draft RPKI RP Requirements January 2019 9.2. Informative References [I-D.ietf-sidrops-bgpsec-rollover] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router Certificate Rollover", draft-ietf-sidrops-bgpsec- rollover-04 (work in progress), December 2017. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [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, . [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, . [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, . [rsync] "rsync web page", . Authors' Addresses Di Ma ZDNS 4 South 4th St. Zhongguancun Haidian, Beijing 100190 China Email: madi@zdns.cn Stephen Kent Independent Email: kent@alum.mit.edu Ma & Kent Expires August 1, 2019 [Page 11]