Brian,
Tp paraphrase an old joke, we've established what kind of engineers we
are, we're just haggling over the overlap interval.
Your proposal includes a period when old and new INR holders have valid
credentials, i.e., an overlap of valid RPKI objects. I didn't see any
indication in your message of a proposed max overlap interval. Currently
we no specified max overlap,so both approaches really overlap, so to speak.
You suggested pre-publication of signed objects with validity start stop
time. Since you are discussing the current RPKI design, I presume that
you are familiar with the syntax of certs, CRLs, and RPKI signed
objects, as specified in the RPKI RFCs. So you realize that certs and
ROAs and manifests all contain validity intervals already. Thus one
could pre-publish instances of the objects involved in an INR transfer,
as you suggested, consistent with the standard syntax. of course, all of
these pre-published objects are invalid until the validity start time.
We make use of the RFC 5280 certificate path validation rules, as
augmented by the 3779 extension processing (as per RFC 3779).
Certificate path validation as per 5280 will cause the certificates that
are not yet valid to be rejected until they become valid, and thus
objects that are validated by these certs, e.g., ROAs and manifests, are
similarly invalid until that time. So, pre-publication would allow one
to push out certificates to the new INR holders prior to them being
"activated." That could be used to reduce the contribution to the
overlap interval that is attributable to the time we allow for RPs to
fetch RPKI data.One would have to persuade RPs to not discard such
not-yet-valid objects, within a reasonable time window, but that might
be done. (One has to limit the window, since none of these objects can
be validated and that creates a DoS vector ...)
Ifwe allow a reasonable time for RPs to have fetched the not-yet-valid
objects, then when they "turn the crank" to process local caches after
the objects have become valid, the RPs would accept them. But, I've
never hear anyone suggest that one ought to try to impose a global,
coordinated, RPKI object processing time on all RPs. (That, in itself
would be a security concern.) So there may be limits here as to how much
the overlap can be reduced by this strategy.
Also, are there any other examples you can cite where every network
operator is expected to perform some activity, at the same time
(relative to UTC), every day, around the world? What is the accepted
norm for clock sync among all ISPs today, and what processes rely on the
extant precision and accuracy of synchronized clocks at all ISPs? Not
being an operator, I really don't know the answers to these questions.
Anyway, if we were to adopt your suggestion, the benefit might be that
the overlap interval need be determined primarily by the time needed to
accommodate skew in RPs posting, fetching, and processing RPKI objects.
Rather the overlap interval would be a function of what folks consider
to be a comfortable interval to accommodate human processes (and errors)
for the INR transfers.
I don't know that this time scale as being one that requires carefully
coordinated clocks at all RPs, especially since we don't have a
candidate overlap interval value on the table. Moreover, since there is
an overlap interval in either case, it's not immediately clear how hard
we should work to reduce it. What overlap interval did you envision?
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
