Tree Hints for the Resource Public Key Infrastructure (RPKI)
draft-kwvanhove-sidrops-rpki-tree-hints-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Koen van Hove | ||
| Last updated | 2022-06-16 (Latest revision 2021-12-13) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
In the Resource Public Key Infrastructure (RPKI), holders of IP address space can become a Certification Authority (CA), optionally hosting their repository. They can also delegate (part of) their resources to subordinate CAs, who in turn may do the same. This CA hierarchy forms a tree structure. Relying Party (RP) software walks this tree and determines the current valid objects. An underlying assumption is that this tree is a reasonable size, and that the information can be processed within reasonable time. This assumption is not guaranteed to hold. This document describes two new extensions, "maxDescendants" and "maxVrps", that add constraints for use in RP processing that ensure this assumption holds.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)