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
- [sidr] WGLC for draft-ietf-sidr-algorithm-agility… Sandra Murphy
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Christopher Morrow
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Arturo Servin
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Paul Hoffman
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Danny McPherson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Roque Gagliano
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Roque Gagliano
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Samuel Weiler
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Danny McPherson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Danny McPherson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Roque Gagliano
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Randy Bush
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Christopher Morrow
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Sean Turner
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Christopher Morrow
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil