Eric,
In response to your message from last week.
Some candidate text dealing with the timeline document in section 2:
An additional document, the algorithm transition
timeline will be published as a BCP (?) to define
the timeline for the algorithm suite transition.
It will defines dates for the phase transitions,
consistent with the descriptions provided in
Section 4. It is RECOMMENDED that the timeline
document be developed by the entities that act as
CAs, RPs, and repository operators in the RPKI,
e.g., IANA, Internet Registries, and network
operators. It is also RECOMMENDED that the
timeline document describe procedures to track
the progress of the transition and to amend the
timeline, e.g., if problems arise in implementing
later phases of the transition.
You raised a question about the implications for
CAs that do not transition to the new algorithm
suite, motivated by the last paragraph of section
11. You posited that " the implication is that
if any CA doesn't keep up (so to speak) they are
considered invalid and therefore would be
un-routable?" That's not quite accurate. At the
end of Phase 4 the Internet resources of any CAs
that have not made the transition will be treated
the same as resources that have not been
protected via RPKI certificates and ROAs.
Participation in the RPKI is voluntary, so there
may always been unprotected resources in the
public Internet. These are not un-routable, but
they are subject to hijacking.
You suggested that we codify how the community
should deal with problems that motivate delaying
a phase transition. We're not writing the
timeline document now, but the text at the
beginning of this message is an effort to make
sure such considerations are addressed in that
document.
You suggested that we add text, for each phase,
saying " what to do if its success requirements
are not met (exceptions, error legs, etc)."
Here's my proposed initial text to address your
question:
Phase 0 is the start of the process, when a new
algorithm suite has been selected and the
timeline published. The only problem I envision
that might arise at this stage, prior to Phase 1,
is a discovery of a problem that makes Suite B
unacceptable. If this situation arises, the
algorithm document will have to be reissued with
a new Suite B, and the timeline document will be
reissued.
Phase 1 requires all CAs to be able to issue
certificates under Suite B. If a problem arises
that makes this infeasible for a substantial
number of CAs, the timeline document can be
reissued, pushing back this date, and dates for
subsequent milestones. CAs that are capable of
issuing Suite B certificates may continue to do
so, if requested by their child CAs. Since this
phase does not require any RPs to process signed
objects under Suite B, and since Suite B product
SHOULD be stored at independent publication
points, there is no adverse impact on RPs.
Phase 2 requires that CAs MUST publish all signed
products under Suite B, as well as Suite A, and
RP MAY be prepared to validate these products
using Suite B. If a problem arises that makes
this infeasible for a substantial number of CAs,
the timeline document can be reissued, pushing
back this date and dates for subsequent
milestones. (Since the processing requirement for
RPs here is MAY, if RPs have problems with Suite
B products this does not require pushing back the
Phase 2 milestone, but it does motivate delaying
the start of Phase 3.) CAs that are capable of
publishing products under Suite B may continue to
do so. Phase 2, like Phase 1, does not require
any RPs to process signed objects under Suite B,
and since Suite B product SHOULD be stored at
independent publication points, there is no
adverse impact on RPs.
Phase 3 requires that RPs MUST be able to process
Suite B signed products, and RPs are encouraged
to validate signed products using Suite B.
However, each RP is required to be able to fall
back to using the Suite A product if the Suite B
product set cannot be validated. As Section 4.6
notes, there are no CA behavior changes at this
phase, so there is no requirement for CA
rollback. If a substantial number of RPs are
unable to process product sets signed with Suite
B, this Phase could be delayed, and subsequent
milestones pushed back. There is no rollback
required here, as there is no change in CA
behavior.
Phase 4 begins the phase out of Suite A. At this
phase products sets signed under the old
algorithm suite may begin to disappear, i.e., CAs
MAY choose to not publish them anymore. This
phase should be delayed if it is determined that
many RPs are not capable of processing the new
algorithm suite. There is no rollback required if
this phase is delayed. However, CAs should be
reminded to not remove old algorithm suite A
product sets if this phase is delayed.
Section 4.8 describes EOL for the old algorithm
suite, i.e., it kills off all support for the old
algorithm suite. It is described as a return to
Phase 0. If we wait until Phase 0, then it may be
a very, very long time before the old Suite A is
killed off. We may want to revisit this, i.e., if
we want to kill off the old algorithm suite
sooner.
Your last comment deals with the question of
top-down vs. laissez faire algorithm transition.
I think your comment is that we cannot mandate
adherence to the transition process and timeline.
Use of the RPKI, both the issuance of signed
products and their consumption, is optional. So,
no, we cannot mandate adherence to this timeline.
But, we can establish a transition process and
timeline for all CAs and RPs that chose to follow
it. The goal in establishing the process and
timeline is to minimize the cost to the
community, as a whole, for the transition.
Externalization of cost is the appropriate term
here (from economics perspective) to describe
what happens if one were to adopt the laissez
faire approach. (Chaos might be an alterative
term :-))
First, not that a CA cannot unilaterally decide
to transition to a new algorithm. There is a
requirement that the issuer of its certificate is
prepared to accept a certificate request under
the new algorithm suite (because of the PoP
requirement).
The exponential growth arises if we have Suite A
and B product sets at each tier. If we allow CAs
to "do their own thing," there is the potential
for four combinations:
- a Suite A certificate issued under Suite A
- a Suite A certificate issued under Suite B
- a Suite B certificate issued under Suite A
- a Suite B certificate issued under Suite B
If we allow all of these combinations, which may
be needed to allow RPs to process signed products
during the transition, then each tier has this
potential 4-way branching, to accommodate RPs at
different stages of algorithm capability. If you
want more details, I suggest reviewing the slides
from the SIDR WG meeting that I believe I cited
previously. When Geoff Huston initially noted
this problem, I disagreed, and it was not until I
started to write the spec that I realized what he
meant.
To avoid more flame wars, I will duck your
question about my views on DNSSEC and
accommodation of different algorithm suites :-).
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
