Hello all
I'm going to provide the best answers I can to the questions that have
been made in the mailing list. I'm spinning a new thread so we don't
hijack the WG directionz one.
Intentionally I'm **not** going to answer any emails that invoke
politics. Those who feel they need answers from that side of things know
who you can refer to.
First of all, thanks for the feedback. To be honest, I am quite
surprised that it took this long. This document was first presented in
Buenos Aires, which was almost 5 months ago.
This decision to move to 0/0 is a solution born more of necessity than
desire for the following reasons:
a. There exist political obstacles to a global trust anchor of 0/0 that
are, at the moment and for the foreseeable future, insurmountable. This
is regrettable, but also a reality and should not be denied.
b. Due to the above, there is an inconsistent model of trust anchors
published by the RIRs. This solution does fix this problem, making the
overall RPKI at least consistent.
c. The RPKI does not have a graceful mechanism for which to handle "ERX
space" (networks managed by one RIR placed under the IANA allocation for
another RIR). As inter-RIR transfers become more common place, the ERX
space will become more fluid and a source of conflict. Management of ERX
space is all the more difficult to manage under the RPKI as there is no
make-before-break mechanism built-in to the RPKI nor does the RFC 6492
protocol provide a mechanism for parent-to-child messaging with which to
enable a make-before-break mechanism.
d. Given the fluidity of the ERX space mentioned above and the current
validation algorithm, there is foreseeable fragility of the system that
is solved by this solution. The IETF is working on changing the
validation algorithm, but this change has been in progress for years and
is still dependent on a timetable for publication of new ROAs by all CAs
and installation of new software by all RPs.
e. Given that there is no global trust anchor and the RIRs each operate
offline Trust Anchors for security, having just the resources actually
assigned or allocated by the respective RIR, would require a trip to the
datacenter for each inter-RIR transfer which will incur delays and
result in resources showing up at two RIRs simultaneously, or none of
the RIRs for some time as TA certificates are updated independently.
Thanks to all!
-Carlos
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
