Folks,
I realize I am very late in commenting on this doc, but I was on
vacation for
a month, and upon return I am working through 2300+ new messages, so ...
I have three concerns with the document:
1- the doc presumes that the solution to the principle problem cited is
to change
the validation alg. That may be the right outcome, but I think it might
be more
appropriate to focus on the primary, cited concern, i.e., that a error
in the
3779 extension(s) of cert for a CA with many children might cause
problems for many of the
children. Geoff specifically raised this issue for RIRs, and because
they are acting
as TAs, they have the ability to issue a new self-signed cert that
adversely impacts
many of their children. NIRs and very large ISPs don't acts as TAs, so
errors by them
affect certs issued by them to individual children.
One could begin by describing what we believe to be best practices for
RPKI CAs
with regard to 3779 extension checks. For example, for a CA that is also
a TA,
it makes sense to run RP validation for every cert issued by the CA
prior to
publishing a new self-signed cert. That simple process would detect any
child certs
that would be rendered invalid by an error if the sort cited by Geoff.
This RP check
can be automated trivially, since the CA/TA has direct access to all of
the currently-
valid certs that it has issued.
For a CA that is not a TA, the impact of a 3779 change is limited to the
subtree for
the affected cert. Here too, it makes sense for the CA to run an RP
check whenever
it is reducing the scope of the 3779 extensions. So, the automated check
to run here
would entail two parts: first see if a cert that is being re-issued
represents a reduction
in scope for the 3779 extension(s); second, fetch the certs issued by
the CA whose cert
is being reissued, and see if any of them will be invalidated by the
change.
If those with experience operating RPKI CAs have other suggestions for
good practice wrt
avoiding the problem Geoff cited, they too should be part of a doc
addressing this issue.
(I'd also like to verify that the RIRs are, or are not, performing the
first set of checks
today, for their ss-certs.)
Geoff has argued that other benefits accrue from relaxing the 3779 part
of the path
validation procedure. There is not agreement on his other examples. For
example, we
have an I-D describing how to automate more of the resource transfer
process (draft-barnes-sidr-tao-00). The mechanism described there would
benefit a little from a relaxed
3779 validation check, but only in very limited circumstances. So, that
use case does
not seem especially compelling.
2- A separate concern is that the candidate doc contains two separable
cases: one relaxes
path validation by not mandating that every subordinate cert contain
only a subset
of the resources in the parent cert. The other case introduces the
notion of a join
into the RPKI tree structure. This latter case was extensively
criticized during the
SIDR WG meeting, by a number of folks. I suggest that case not be part
of a new WG
doc at this time.
3- My final concern/observation, is that the text in the doc that
describes how to
relax the 3779 aspects of path validation is not, as stated, viable.
Specifically,
it appears to assume that path validation is performed only for EE
certs. In the RPKI,
we effect path discovery top down, based on our model for discovering
CAs and
their children. (In PKIs in general, path discovery may be top down or
bottom up, or
both toward the middle, but the RPKI is not a generic PKI.) Because of
the top-
down approach, it makes sense for RP software to validate each newly
discovered
CA. This is not only an efficiency issue, but also an anti-DOS feature.
Thus the
description of how to modify the current 3779 path validation alg is not
adequate.
I believe it can be fixed, and I have indicated how it might be fixed in
(private)
message excahnges with Geoff. Thus this concern is not a reason to
reject work on this
topic, but it does suggest that a viable algorithmic description might
be a prerequisite
for adopting a version of this doc.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
