sidrops D. Ma Internet-Draft ZDNS Intended status: Informational Y. Zhang Expires: 5 September 2024 Peng Cheng Laboratory 4 March 2024 A Reference Implementation of Ascertaining RPKI Signed Objects to be Validated in Incremental Updates draft-madi-sidrops-partial-validation-00 Abstract This document describes a reference implementation of how an RP ascertains which RPKI signed objects that need to be validated during a transaction of RPKI incremental update from the perspective of this RP. 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 5 September 2024. Copyright Notice Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Ma & Zhang Expires 5 September 2024 [Page 1] Internet-Draft RPKI Partial Validation March 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Correlations of RPKI Signed Objects . . . . . . . . . . . . . 3 2.1. Horizontal Correlation . . . . . . . . . . . . . . . . . 3 2.1.1. Definition . . . . . . . . . . . . . . . . . . . . . 3 2.1.2. Implementation . . . . . . . . . . . . . . . . . . . 3 2.1.3. Horizontal Involvement Discovery . . . . . . . . . . 4 2.2. Vertical Correlation . . . . . . . . . . . . . . . . . . 4 2.2.1. Definition . . . . . . . . . . . . . . . . . . . . . 4 2.2.2. Implementation . . . . . . . . . . . . . . . . . . . 5 2.2.3. Vertical Involvement Discovery . . . . . . . . . . . 5 2.3. Involvement Correlation . . . . . . . . . . . . . . . . . 6 2.3.1. Definition . . . . . . . . . . . . . . . . . . . . . 6 2.3.2. Implementation . . . . . . . . . . . . . . . . . . . 6 2.3.3. Target Object Discovery . . . . . . . . . . . . . . . 8 3. Procedure of Target Object Discovery . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Due to the hierarchical allocation of the Internet number resources and the trust model in the RPKI, an update to a RPKI signed object (resource certificate, ROA, CRL or Manifest for instance) in the RPKI might lead to change of validation status of other RPKI signed objects. It is desirable to ascertain all the affected parts of the RPKI trees and perform the corresponding validation tasks as quickly as possible in order to inform the routing system of those changes in time. Note that RPKI signed object (so called "RSO") in the context of this document generally includes resource certificate, CRL, manifest, ROA and any other signed data derived from the RPKI.The RPKI Relying Party (RP) periodically takes incremental updates. The validation status of an RSO might be subject to change due to another updated RSO. RFC6487[RFC6487] and RFC8360[RFC8360] specifies the certificate validation procedure in terms of syntax, leaving all the software engineering issue to private implementations such as RFC8488[RFC8488]. Ma & Zhang Expires 5 September 2024 [Page 2] Internet-Draft RPKI Partial Validation March 2024 Comprehending the characteristics of different RPKI signed objects and the correlations among them, this document describes a reference implementation of ascertaining RSOs that need to be validated after a transaction of RPKI incremental update from the perspective of this RP, before performing the RPKI validation specified by RFC6487[RFC6487] and RFC8360[RFC8360]. It is important to note that this document does not syntactically bring changes to validation of RPKI signed objects in any sense. 2. Correlations of RPKI Signed Objects In order to ascertain RSOs to be validated in incremental updates, the reference implementation (so called "the process" in this document) establishes some structured data in the memory. 2.1. Horizontal Correlation 2.1.1. Definition RSOs with the same AKI value and the very AKI constitutes a specific correlation called the RPKI horizontal correlation. The union set of those horizontal correlations are defined as the Horizontal Correlation Set (HCS). 2.1.2. Implementation The process utilizes a mapping table to implement a horizontal correlation. The AKI value serves as the key of the mapping table, the elements of which are the memory pointers of those RSOs in this horizontal correlation, constructed in an unordered array. HCS is always maintained in the memory by the process. Ma & Zhang Expires 5 September 2024 [Page 3] Internet-Draft RPKI Partial Validation March 2024 +--+--+--+--+--+--+--+--+--+--+--+--+ | | + + | Key=AKI | + + | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | | array[0]=0xa1 |-------> | ROA/EE | + + + +--+--+--+--+--+--+ | | | + +--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | Value=Array | array[1]=0xb1 |-------> | CRL | + + + +--+--+--+--+--+--+ | | | + +--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | | array[2]=0xc1 |-------> | MFT/EE | + + + +--+--+--+--+--+--+ | | | +--+--+--+--+--+--+--+--+--+--+--+--+ Figure 1: Example of an element of Horizontal Correlation Set 2.1.3. Horizontal Involvement Discovery If the validation status of an RSO X needs to be verified due to the update of an RSO Y that is in the same horizontal correlation with X, X is considered to be horizontally involved with Y, the discovery of which is called Horizontal Involvement Discovery. 2.2. Vertical Correlation 2.2.1. Definition An RSO (Primary Object) and its all adjacent child RSOs constitutes a specific correlation called the RPKI vertical correlation. The union set of those vertical correlations are defined as the Vertical Correlation Set (VCS). The process establishes the vertical correlation for every resource certificate in the RPKI. Ma & Zhang Expires 5 September 2024 [Page 4] Internet-Draft RPKI Partial Validation March 2024 2.2.2. Implementation The process utilizes a mapping table to implement a vertical correlation. The SKI value of the Primary Object in this vertical correlation serves as the key of the mapping table, the elements of which are the memory pointers of its adjacent child RSOs in this vertical correlation, constructed in an unordered array. VCS is always maintained in the memory by the process. +--+--+--+--+--+--+--+--+--+--+--+--+ | | + + | Key=SKI | + + | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | | array[0]=0xa2 |-------> | ROA/EE | + + + +--+--+--+--+--+--+ | | | + +--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | Value=Array | array[1]=0xb2 |-------> | CRL | + + + +--+--+--+--+--+--+ | | | + +--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | | array[2]=0xc2 |-------> | MFT/EE | + + + +--+--+--+--+--+--+ | | | +--+--+--+--+--+--+--+--+--+--+--+--+ Figure 2: Example of an element of Horizontal Correlation Set 2.2.3. Vertical Involvement Discovery If the validation status of an RSO X needs to be verified due to the update of the primary object Z in the vertical correlation, X is considered to be vertically involved with Z, the discovery of which is called Vertical Involvement Discovery. Ma & Zhang Expires 5 September 2024 [Page 5] Internet-Draft RPKI Partial Validation March 2024 2.3. Involvement Correlation 2.3.1. Definition All the RSOs that are either horizontally or vertically involved with an RSO X, together with the RSO X itself, constitute a specific correlation called the RPKI involvement correlation. X is defined as the primary object of this correlation and the others defined as target object of this correlation. The union set of those involvement correlations are defined as the Involvement Correlation Set (ICS). 2.3.2. Implementation The process utilizes a mapping container to implement an involvement correlation. The unique identifier of this correlation is generated with hash of download path, filename, and other information, serves as the key of the mapping container, the elements of which are the memory pointers of these target objects in this involvement correlation, constructed in an unordered array. ICS is deleted from memory by the process after a transaction of RPKI incremental update from the perspective of this RP. Ma & Zhang Expires 5 September 2024 [Page 6] Internet-Draft RPKI Partial Validation March 2024 +--+--+--+--+--+--+--+--+--+--+--+--+ | | + + | Key=Hash | + + | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | | array[0]=0xa1 |-------> | ROA | + + + +--+--+--+--+--+--+ | | | + +--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | | array[1]=0xb1 |-------> | CRL | + + + +--+--+--+--+--+--+ | | | + +--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | | array[2]=0xc1 |-------> | MFT | + + + +--+--+--+--+--+--+ | | | + Value=Array +--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | | array[3]=0xa2 |-------> | ROA | + + + +--+--+--+--+--+--+ | | | + +--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | | array[4]=0xb2 |-------> | CRL | + + + +--+--+--+--+--+--+ | | | + +--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | | array[5]=0xc2 |-------> | MFT | + + + +--+--+--+--+--+--+ | | | +--+--+--+--+--+--+--+--+--+--+--+--+ Figure 3: Example of an element of Involvement Correlation Set Ma & Zhang Expires 5 September 2024 [Page 7] Internet-Draft RPKI Partial Validation March 2024 2.3.3. Target Object Discovery For a given updated RSO X, the task of establishing the involvement correlation of X is called Target Object Discovery of X. 3. Procedure of Target Object Discovery The procedure of target object discovery is as follows: 0) Bootstrapping The RP performs full update synchronizing with RPKI repositories, validates RSOs and constructs HCS and VCS in the memory, according to section 2.1 and section 2.2 respectively. 1) Performing incremental update The RP performs incremental update, synchronizing with RPKI repositories. 2) Constructing the ICS The RP updates the HCS and VCS by checking the deleted and added RSOs compared with the current local cache stored and then executes target object discovery of those updated and newly added RSOs, constructing the ICS in the memory. Note that given different types of RSOs are semantically different and have got different functions in the RPKI context, the procedure of target object discovery of RSOs with different types vary from one to another. 3) Validating Target Objects The RP validates all the target objects in ICS, following the standardized RPKI certificate path validation, updating RTR output. 4) Deleting the ICS The RP deletes the ICS from memory. 5) Updating the local cache The RP updates the local cache as a new version stored. Ma & Zhang Expires 5 September 2024 [Page 8] Internet-Draft RPKI Partial Validation March 2024 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | + Bootstrapping + | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | v +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | + Performing incremental update +-----------+ | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | | v ^ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | + Constructing the ICS + | | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | ^ | | v | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | + Validating Target Objects + | | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ^ | | | | v | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | + Deleting the ICS + | | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ^ | | v | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | + Updating the local cache +----->-----+ | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 4: Procedure of Target Object Discovery Ma & Zhang Expires 5 September 2024 [Page 9] Internet-Draft RPKI Partial Validation March 2024 4. Security Considerations TBD 5. IANA Considerations None. 6. Acknowledgements The authors would like to thank tbd for their helpful review of this document. 7. References 7.1. Normative References [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [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, . 7.2. Informative References [RFC8488] Muravskiy, O. and T. Bruijnzeels, "RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation", RFC 8488, DOI 10.17487/RFC8488, December 2018, . Authors' Addresses Di Ma ZDNS Floor 21, Block B, Greenland Center Chaoyang Beijing, 100102 China Email: madi@zdns.cn Ma & Zhang Expires 5 September 2024 [Page 10] Internet-Draft RPKI Partial Validation March 2024 Yu Zhang Peng Cheng Laboratory Nanshan Shenzhen, 518055 China Email: zhangy08@pcl.ac.cn Ma & Zhang Expires 5 September 2024 [Page 11]