Brian,
I believe the collection of SIDR documents do a reasonable job
explaining the underlying assumptions and motivations for the SIDR
work. Still, we'll revisit them to try to minimize the ambiguities
you perceive. Nonethelsss, let me summarize:
The RPKI is intended to parallel the address space (and AS #)
allocation hierarchy, from IANA, to RIRs, to NIRs (where applicable)
to ISPs (aka LIRs) and PI subscribers, ...
We never talk about "owning" address space, because IANA and the RIRs
do not use that term. We use the term "resource holder" to refer to
an entity who holds address space or AS numbers. The term refers to
the entity that is recorded in the applicable RIR (or IANA) database
as the holder of the resource in question.
Thus the resource certificates issued by registries are alternative
representations of the registry database records, pared down to the
essential data for the routing security goals of interest. They are
only part of the overall set of data needed to help improve routing
security, but they are a critical first step.
Given this model, a ROA is generated by the entity listed as the
resource holder, because that entity is the one who chooses the
ISP(s) that originate the route (i.e., is the origin AS in BGP terms)
for the prefix (ignoring for the moment the issue of route
aggregation).
A resource holder might ask the RIR (or NIR or ISP) from which a
resource was allocated to manage the RPKI data on its behalf, but
that should be done in a fashion that does not make such
"outsourcing" visible to the relying parties processing RPKI data.
(Such outsourcing is common for commercial, TTP PKIs as well.) I
believe that the folks at APNIC and RIPE have indicated that they are
prepared to provide such services for their members.
There is not an intent that ROAs represent a substantial departure
from the current model, as you suggest. The intent is for a resource
holder be able to use a ROA to identify, in a secure, independently
verifiable fashion, the identity (in the form of an AS #) of entities
authorized to originate routes for the prefix. The IRR databases try
to do this, and more, via RPSL entries, but the security there is not
as good as what can be achieved via deployment of the RPKI.
Hope this helps.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
