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

Eric Osterweil <eosterweil@verisign.com> Tue, 15 November 2011 04:29 UTC

Return-Path: <eosterweil@verisign.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 CEA1B11E80A4 for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 20:29:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.576
X-Spam-Level:
X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 rA7cOCQxoO82 for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 20:29:07 -0800 (PST)
Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 87A1311E8175 for <sidr@ietf.org>; Mon, 14 Nov 2011 20:29:06 -0800 (PST)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTsHqib69UnG9NRxlKl7ank+5jDeHYrrS@postini.com; Mon, 14 Nov 2011 20:29:06 PST
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pAF4Subv027577; Mon, 14 Nov 2011 23:28:56 -0500
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.69]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 23:28:55 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <p06240802cae77c38789d@[172.20.1.65]>
Date: Tue, 15 Nov 2011 12:28:48 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <A3CAD2A6-D33E-4D7D-ACA9-06D92E1B99E7@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> <p06240803cae62a2b13af@[128.89.89.129]> <E54B2072-87B3-4D9A-B1D7-0146A0B51274@verisign.com> <p06240802cae77c38789d@[172.20.1.65]>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 15 Nov 2011 04:28:56.0175 (UTC) FILETIME=[167A27F0:01CCA34F]
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: Tue, 15 Nov 2011 04:29:07 -0000

On Nov 15, 2011, at 10:53 AM, Stephen Kent wrote:

> Eric,
> 
> 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?

Yes, there is a misunderstanding.  This draft is documenting a formal process.  The snipped text included the statement:
"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."

I really think that the procedures associated with this process need to be documented here in the same place (i.e. one draft).

> 
>> ...
>> 
>> 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?

After Phase 4, when some CAs may  be orphaned.  To quote the draft:
"a[n] RP that does not follow this process will lose the
   ability to validate signed products issued under the new algorithm
   suite."

> 
>> 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 determination.

Kewl, thnx.  As a broad question, do we think there will be a point when we can name an operational body who will manage this process, and if so, will we put this in a draft?

>> ...
>> 
>> 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 later?
> 
> that's not a sentence :-).

Yeah it is, I can speak to this at the mic... ;)  In the meantime:
Are we talking about making this an experimental expedition?  Follow on question, are we prepared to create a globally applicable system later?

>>   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 .

No, I was questioning the global applicability.  I am worried that the way BGPsec and RPKI are currently married is not globally applicable, in the current form. 

> Neitehr of these observations conflict with the fact that its use by an network operator is optional.

True, but my point is still that there is a rather striking misalignment between the design and operational invariants.  I'm trying to see your points and how this might not be true, but claiming that we've agreed when it's plain that we have not is... not as productive as it could be... :)

> 
>>   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.

I think the distinct lack of another instance of this kind of operational requirement in modern Internet-scale systems should be cause for pause here.  As I said back at the beginning of this thread:
"Sorry, but I think freedom from global coordination is more than an inconvenient, or unpalatable, concept.  It is something that (afaict) has been an inherent requirement in those Internet-scale systems that have survived to date.  I don't think there is any precedent of an operational system of this scale that requires this level of global coordination of its configuration, is there?  What Internet-scale system of a scale remotely as large as BGP has this kind of global coordination model?  What is the evidence that such an approach will work here?"


>> 
>> 
>> > 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? ;)
> 
> no.

Then I would really like to understand.  As DNSSEC (though not perfect, in any way) is a system that has reached deployment trials and has a growing body of operational practices, what were the "less rigorous" criteria that were "not great?"  Maybe we'll all agree, or maybe we'll all learn...

Eric