Joel,
My reply was to specific comments made by Terry, not David's message.
David's message was at a higher level. My response (which I did not
send) to the question David stated is no, the SDIR model does not
assume that IANA or the RIR control routing any more than they do
today. They allocate addresses and ASNs, and the RPKI just takes info
form the databases maintained by these organizations and represents
them in a digitally signed format. This format enables ISPS and other
address space holders to generate signed assertions about what ASNs
are authorized to originate routes. Thus the issuance of certs by
IANA and the RIRs enables ISPs (and others) to improve certain
aspects of routing secruity IF they choose to make use of these certs
as part of route verification processes.
Nonetheless, I will reply to the comments you made.
...
If there is such a hierarchy, tehn, look at what happens from a leaf
ISP down the tree. They need to reliably be able to advertise their
routes, and have everyone trust their advertiseements if they sign
with the key they registered.
access and trust are both necessary, but are addressed by somewhat
different mechanisms.
Given the scope, this almost inherently requires that there be a
single (or may a small number of disjoint) starting point.
Otherwise, receivers will not have access to and trust of the chains.
But now turn it around. Suppose that ISP is unsure as to whether
they actually trust the hierarchy. Or even if they trust it now,
they are concerned that with a political change, they might not
trust the situation then. Yes, you can argue that the ISP can
register with whomever they like. But that is only useful if there
is trust chain that other people believe between them and that
whomever.
I note that there are multiple IRR databases, not just the ones
operated by the RIRs. Those databases require ISPs (RPs in the RPKI
context) to learn (via out-of-band means) where to find these
databases to download the RPSL objects. That is analogous to the RPKI
situation.
The RPKI design allows very substantial distribution of the RPKI
data, and the inclusion of URLs in the certs makes it possible to
discover locations "below" publication points that an RP accepts as
authoritative. So, the repository side of TA management calls for RPs
to select TAs and then follow the pointers from those certs.
Pesonally, I hope that the RIRs offer to host data for their members,
and sub-allocations, etc. and that most RPs will elect to use those
registries, at least as starting points. But, a suspicious RP has
other options.
Your last sentence (above) is correct (despite ending prematurely
:-)) but it is also a fundamental characteristic of any hierarchic
system when users of the system want to make provisions to "trust"
alternatives to the default hierarchy. I think the RPKI design does a
better job of architecting how to do this than most such systems. A
few users probably will be sufficiently concerned about misbehavior
that they will make alternative publication/certification
arrangements. But, I doubt that this will be true of the vast
majority of users.
This turns into a massive political and public relations pain.
I don't know a better answer.
But ignoring this dimension of the deployment problem will not serve us well.
This is not being ignored. My presentation on how to perform local TA
management was targeting this issue, and I have received very
positive feedback from several folks saying that this goes a long way
toward addressing their concerns. I think the painful experience that
David noted with regard to DNSSEC root issues is influencing the RPKI
design.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
