Internet DRAFT - draft-madi-sidrops-partial-validation
draft-madi-sidrops-partial-validation
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,
<https://www.rfc-editor.org/info/rfc6487>.
[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>.
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,
<https://www.rfc-editor.org/info/rfc8488>.
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]
