Sandy,
...
When this working group was developing the RPKI specifications, the RIRs essentially
asked us not to specify how the "movement of resources across registries" would
take place. I for one accepted this at the time because it looked like an issue between
RIRs. This document is calling for a make-before-break certificate issuance capability.
Maybe there are other motives too.
There are two cases.
One is the transfer case and the need to revise certs upward on the giving side
and downward on the receiving side. That's the make-before-break part.
The other is the problem of removing resources from certs - one CA reissues a
"smaller" cert, and reissuing has to take place down the chain for the
resources that are retained, in order to keep the encompassing rules valid. The pain is
felt in the CA's descendants until other CAs get their re-issuance done.
The second case merits further analysis, I think.
If the INRs being removed are not in use at lower tier CAs, then maybe
they are not allocated
in certs issued to those CAs, and the process is trivial. If the INRs
have been allocated
to lower tier CAs, and thus they are represented in the certs of the
CAs, then one would not
expect to remove the INRs in a top down basis anyway, right? One would
expect the lowest tier
CA holding the INRs that are to be returned to be the fist to relinquish
them. Then this would
propagate up the chain, consistent with each CA updating its databases
to reflect the new
allocation status. RPKI docs consistently state that certs are issued ti
reflect the INR
databases of the entities acting as CAs. These databases ought not be
updated to reflect a
return of INRs until that return has taken place. So, it seems that the
only artificial timing
issue is the lag one has to accept in terms of RPKI repository (and
cache) propagation. But,
we already know that such lags are intrinsic in the RPKI. Also, what are
the requirements,
vis-a-vis timing, for completing INR removal? How man tiers of CAs are
involved?
RFC 3779 has been implemented. For example, OpenSSL implements RFC 3779, and
others make use of this certificate handling software. We are not talking
about a little tweak to such a library. Implementation would require a path
validation parameter to pass the content of the ROA.
Not sure that's the case. I think all RPKI recipients now need to do a
computation of which of a cert's resources are valid, which are not. The
*recipients* decide what the certificate says. This will impact interpretation
of a ROA but I don't think it requires something that has to get passed around
with the ROA.
Having looked at our RP software, I believe the revised vaidation
approach (based on the current,
informal spec) would require that we compute the intersection of parent
and child CA certs along each
cert path and store the result. This is independent of whether one is
later using the path to
validate a ROA (with it's embedded EE cert) or a router cert (in
BGPSEC). Maybe Russ was alluding
to the need to pass that intersection of INR sets to the ROA validation
process.
As I understand the situation, the existing specification works, but it imposes
some restrictions on the order that certificates that must be issued and
distributed.
There's a order problem in the transfer case and a timing problem in the
reduction case.
This seems like a good characterization, but I question whether the
timing restrictions
are really important. Also, in the INR transfer case, I've seen detailed
slides at APNIC
meetings showing how inter-RIR xfers work today. It is a process with a
number of steps,
and some, limited parallelism. It's not clear how much additional
parallelism one can
achieve with the proposed validation procedure, without violating the
CP. We have a spec
of the details of INR xfer in TAO. We don't yet have an analogous spec
for the proposed
validation model. Until we do, we can't accurately compare the proposed
scenario vs. the
existing one.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
