| Internet-Draft | RPKI Partial Validation | August 2024 |
| Ma & Zhang | Expires 27 February 2025 | [Page] |
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.¶
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 27 February 2025.¶
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.¶
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].¶
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.¶
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.¶
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).¶
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.¶
+--+--+--+--+--+--+--+--+--+--+--+--+ | | + + | Key=AKI | + + | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | | array[0]=0xa1 |-------> | ROA/EE | + + + +--+--+--+--+--+--+ | | | + +--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | Value=Array | array[1]=0xb1 |-------> | CRL | + + + +--+--+--+--+--+--+ | | | + +--+--+--+--+--+--+--+ | | | + + + +--+--+--+--+--+--+ | | array[2]=0xc1 |-------> | MFT/EE | + + + +--+--+--+--+--+--+ | | | +--+--+--+--+--+--+--+--+--+--+--+--+
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.¶
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.¶
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 | + + + +--+--+--+--+--+--+ | | | +--+--+--+--+--+--+--+--+--+--+--+--+
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.¶
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).¶
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.¶
+--+--+--+--+--+--+--+--+--+--+--+--+ | | + + | 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 | + + + +--+--+--+--+--+--+ | | | +--+--+--+--+--+--+--+--+--+--+--+--+
For a given updated RSO X, the task of establishing the involvement correlation of X is called Target Object Discovery of X.¶
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.¶
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
+ Bootstrapping +
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
|
v
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
+ Performing incremental update +-----------+
| | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| |
| |
v ^
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| | |
+ Constructing the ICS + |
| | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| ^
| |
v |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| | |
+ Validating Target Objects + |
| | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ^
| |
| |
v |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| | |
+ Deleting the ICS + |
| | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ^
| |
v |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| | |
+ Updating the local cache +----->-----+
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
TBD¶
None.¶
The authors would like to thank tbd for their helpful review of this document.¶