Re: [sidr] Questions about draft-huston-rpki-validation-01

[Stephen Kent <[e-mail]>]

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