Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

Stephen Kent <kent@bbn.com> Mon, 14 November 2011 02:18 UTC

Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901A111E80DF for <sidr@ietfa.amsl.com>; Sun, 13 Nov 2011 18:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.521
X-Spam-Level:
X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFoPNAPiuM2t for <sidr@ietfa.amsl.com>; Sun, 13 Nov 2011 18:18:20 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 211A611E8087 for <sidr@ietf.org>; Sun, 13 Nov 2011 18:18:20 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:45178 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RPm7l-0004Oi-KP; Sun, 13 Nov 2011 21:18:19 -0500
Mime-Version: 1.0
Message-Id: <p06240803cae62a2b13af@[128.89.89.129]>
In-Reply-To: <E9BAE21C-A8EF-4D07-90C1-E8A5FD7F00E7@verisign.com>
References: <CAD6DA02.1C611%terry.manderson@icann.org> <p06240803cad6af1b0ce7@[193.0.26.186]> <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <p06240803cad951813fd9@[193.0.26.186]> <CB6FE413-BEC2-4910-AEEF-98D6EAFD4E83@verisign.com> <p06240802cadde494171b@[128.89.89.6]> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> <p06240811cade1873e723@[128.89.89.6]> <BDA75A7E-2B2D-44A5-A18F-2D7DA01DF3A2@verisign.com> <p06240808cadf618efaa8@[128.89.89.6]> <E9BAE21C-A8EF-4D07-90C1-E8A5FD7F00E7@verisign.com>
Date: Sun, 13 Nov 2011 21:16:48 -0500
To: Eric Osterweil <eosterweil@verisign.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-890885399==_ma============"
Cc: "sidr@ietf.org list" <sidr@ietf.org>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Nov 2011 02:18:21 -0000

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