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

Stephen Kent <> Tue, 15 November 2011 02:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 414F81F0C9F for <>; Mon, 14 Nov 2011 18:58:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.528
X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EE2EF8UJY5v7 for <>; Mon, 14 Nov 2011 18:58:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 01FA11F0C8F for <>; Mon, 14 Nov 2011 18:58:57 -0800 (PST)
Received: from ([]:45538 helo=[]) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1RQ9Eb-000Lm4-63; Mon, 14 Nov 2011 21:58:56 -0500
Mime-Version: 1.0
Message-Id: <p06240802cae77c38789d@[]>
In-Reply-To: <>
References: <> <p06240803cad6af1b0ce7@[]> <> <p06240803cad951813fd9@[]> <> <p06240802cadde494171b@[]> <> <p06240811cade1873e723@[]> <> <p06240808cadf618efaa8@[]> <> <p06240803cae62a2b13af@[]> <>
Date: Mon, 14 Nov 2011 21:53:22 -0500
To: Eric Osterweil <>
From: Stephen Kent <>
Content-Type: multipart/alternative; boundary="============_-890796563==_ma============"
Cc: " list" <>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Nov 2011 02:58:58 -0000


i think we are making  progress. thanks for the feedback.

>I really think we should address these issues in a single document. 
>It seems like splitting this off into a separate/as yet unwritten 
>document is likely to cause some problems.  In particular, since 
>that document does not yet exist, and it may not be written and 
>adopted for some time, this draft will not be complete on its own. 
>I'm worried that it is hard to judge this document's readiness w/o 
>these timeline issues worked out or even broached (as they may 
>demand changes to this process).  Besides, isn't the corpus of 
>drafts rather extensive already (w/o adding another)? :)

My motivation for a separate timetable (vs. timeline) doc is that 
there seems to be some agreement that this doc should be a product of 
the operator community. The alg transition doc is an IETF 
architectural statement, the product of this WG. I can't see 
combining the two.  Did I misunderstand your concern here?

>OK, I see.  But, aren't there second-order effects of this that we 
>have to worry about?  For example, if I am an ISP whose CA performs 
>the rollover properly, but my upstream's CA does not, then their 
>CA's failure to keep up will cause my ISP to no longer be able to 
>participate in BGPsec, right (because I'm no longer part of a 
>contiguous BGPsec island)?  I realize this is a bit different than 
>my original example, but upon thinking about the motivation for my 
>comment, my point was more general.  It was that transitioning a CA 
>to this state can have very undesirable effects.

What you say that you performed the rollover but the CA above you 
didn't can you be more specific, re the phase number?

>s/I envision/we envision/


>kewl, thnx.  One minor nit: can we rephrase one part for clarity. 
>Instead of "If a problem arises that makes this infeasible for a 
>substantial number of CAs," can we just specify a little bit about 
>how this is determined.  Maybe something like, "If <whoever the 
>operational governing body we elect for timeline statements> deems a 
>problem to have arisen that is significant enough to make this 
>infeasible for a significant enough number of CAs..."

Good suggestion. I had already changed the text to the following form.

If it is determined that a substantial number of CAs are unable

Since we don't have a good placeholder for the bracketed entity I 
think it's easier to make the statement without say who makes the 
>First, same minor nit as above.
>Second, do we want to consider the case were we want to rollback 
>(perhaps an alg B has become unsuitable for some reason and we need 
>to choose a new alg B altogether)?  I'm not saying the above text 
>should be yanked, maybe just augmented?

AI had not considered the case of an alg concern at this phase,  Good 
catch. I'll add suitable text to Phases 1-4.

>I think this is a very strange comment (and I note that you said it 
>earlier in this email too).  "Use of the RPKI... is optional."  Is 
>the goal of this system to protect the global routing infrastructure 
>or not?

The goal of this work does not imply that we can force all ISPs to 
adopt it.  We hope that the RPKI will be very widely deployed and 
used, but we acknowledge that it may not me universal. So, both 
initially and perhaps forever, the world will consist of resources 
that are protected by certs and ROAs, and ones that are not.

>   Unless we are talking about making this an experimental 
>expedition, and are prepared to create a globally applicable system 

that's not a sentence :-).

>   If the goal is to secure the global routing system (note I am not 
>saying universal deployment in the foreseeable future, just global 
>applicability), then this is an operational non-starter.

I'm glad that we agree that universal deployment is not a likely near 
term event. We also agree that the RPKI is globally applicable . 
Neitehr of these observations conflict with the fact that its use by 
an network operator is optional.

>   I do not believe it is appropriate for us to try and re-legislate 
>operational axioms in these drafts.  What we could be doing is 
>grossly misaligning this standards work with operational invariants.

I no longer know what you are referring to. I have said that we 
cannot mandate adherence to this process.  We can offer it as a 
preferred approach and hope that it is followed. We have incorporated 
a number of phases so that there is an opportunity to verify the 
status of the transition, and to allow the timeline to be pushed back 
if necessary. if what you are saying is that we ought not specify any 
process that calls for CAs and RPs to try to execute a transition in 
a coordinated fashion, over a long time interval, then we have an 
impasse. The disagreement is based on perceptions, on both of our 
parts, not facts.

>  > 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).
>I'm sorry, I don't understand.

PoP requires the issue of a cert to verify that the cert requester 
posses the private key corresponding to the public key in the cert 
request. So, if CA N requests a cert that contains a key under Alg X, 
CA N-1 (its parent ) cannot issue that cert until CA N-1 has 
implemented Alg X. Does this help?

>>  To avoid more flame wars, I will duck your question about my views 
>>on DNSSEC and accommodation of different algorithm suites :-).
>Shall I take that as a retraction of your comment? ;)