At 2:08 AM -0500 12/4/08, John Curran wrote:
On Nov 6, 2008, at 1:00 PM, Geoff Huston wrote:
Since Sandy's Last Call on this document there have been a few
changes to the document which I should note here.
...
Following advice from Steve Kent, the section on Trust Anchors was
revised (section 6). The change has concerned the terminology used to
described the various structures proposed in the TA model.
The clarifications and additions in section 6.3 are a major
step forward in understanding the intent of the draft with
respect to Trust Anchors. With the improved understanding,
there are some questions raised as to how exactly the full
set of assertions should be obtained for any given Internet
numbering resource.
The draft uses the term "default trust anchor collection" in
section 6.3 ("Relying Parties can assemble the default trust
anchor collection by using the registry TA certificate for each
nominated trust anchor...") but doesn't specify how to navigate
the multiple RPKI hierarchies that occur only in the presence
of a "trust anchor collection", nor does it provide guidance
on to perform overall interpretation of multiple valid assertions
which might occur in presence of a "trust anchor collection".
The semantic logic regarding how to handle sets of overlapping
and contradictory assertions is essential for consistent
interpretation of the certificates contained in the full set
of RIR/IANA RPKI hierarchies. Note that RFC 3779 not only
doesn't provide any assistance in resolving this situation,
it specifically sets rules to prevent such an situation from
occurring:
"Sections 2 and 3 specify several rules about the encoding of the
extensions defined in this specification that MUST be followed.
These encoding rules serve the following purposes. First, they
result in a unique encoding of the extension's value; two instances
of an extension can be compared for equality octet-by-octet.
Second, they achieve the minimal size encoding of the information.
Third, they allow relying parties to use one-pass algorithms when
performing certification path validation; in particular, the relying
parties do not need to sort the information, or to implement extra
code in the subset checking algorithms to handle several boundary
cases (adjacent, overlapping, or subsumed ranges)."
In its present form, the draft departs from the single certificate
hierarchy envisioned in RFC 3779 ("IP address space is currently
managed by a hierarchy nominally rooted at IANA, but managed by
the RIRs"), and thus makes numerous combinations of conflicting
assertions possible for the same numbering resource. Without
unstated information on how to obtain and correctly interpret
such combinations, the ambiguities that result prevent using
the proposed model with multiple RPKI hierarchies to ascertain
information for a given numbering resource with any degree of
certainty. As this is *the* utility value of an RPKI system
for many in the community, I'd recommend we either correct the
model or supply the missing information which will allow for
deterministic use of the total RPKI infrastructure.
/John
John,
I'm not sure what you mean by "multiple valid assertions." If you
mean multiple ROAs that identify different AS'es, then that is an
allowed outcome, as I believe Randy has separately noted. If the ROAs
all can be validated, then they are all equally "good" in the eyes of
the RPKI model. This is true whether we have one TA or multiple TAs.
It think the point to which you may be alluding is that if we have
the five RIRs and IANA as TAs, then a mismatch between IANA's
allocation database and the database of any RIR, or between the
databases of any RIRs, will not automatically be detected by the RFC
3779 path validation mechanism. That observation is correct, but
there's more ...
I once proposed developing software to detect conflicting allocations
(sub-allocations). The proposed was shot down by folks who argued
that transfer of address space among users would cause too many false
positives to make detection mechanisms worthwhile. Thus, even if we
were to adopt a model where IANA is the only default TA, lower tiers
in the nominal hierarchy can still make mistakes that result in
conflicts. The limitation imposed by the 3779 path validation
criteria is that such errors are limited to the set of resources held
by the CA in question. So, if we adopt a model with IANA as the only
root, we do reduce the range of errors that can result in conflicting
allocations, but we do not prevent all such (potential) conflicts.
I can think of ways to help relying parties to detect possible
IANA/RIR and RIR/RIR allocation conflicts in a model where both RIRs
and IANA are TAs, but, as noted above, we have to remember that this
will not deal with all such conflicts.
Finallly, we have to remember that, ultimately, each RP gets to make
its own TA choices. We are offering a default (or putative) set of
TAs as part of the architecture, but we cannot mandate which entities
each relying party will select. Also, ISPs that use RFC 1918
addresses and choose to make use of the RPKI, they will need to
(locally) override the public address space hierarchy anyway.
Steve
P.S. Irrespective of my analysis above, yes, I do prefer a
singly-rooted PKI, with IANA as the only TA, but I can live with a
set of TAs so long as I can count them on my fingers, and they all
are authoritative for the resources in question :-).
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
