Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 29 March 2012 19:11 UTC

Return-Path: <brian.peter.dickson@gmail.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 21BB721E8029 for <sidr@ietfa.amsl.com>; Thu, 29 Mar 2012 12:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.562
X-Spam-Level:
X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 Dody5vmCAB+4 for <sidr@ietfa.amsl.com>; Thu, 29 Mar 2012 12:11:13 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 98AB021E801B for <sidr@ietf.org>; Thu, 29 Mar 2012 12:11:11 -0700 (PDT)
Received: by wibhq7 with SMTP id hq7so311752wib.13 for <sidr@ietf.org>; Thu, 29 Mar 2012 12:11:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a6av5yoiDh6M7cdD234YmYuh+im4IW7KU1xYocbkqtc=; b=aJkstXFpyiE4ZTjQXRJJuq3/j5shOGa9TCu0ZDYftX3rayqs5N0713BNEv2gBIr5iD /y9kITsnLmwiCtUuxPqQ7pA8XyvOOYLQP/u0ftCKFee/dov/I2P9JTITXCTKnzi7TfUz cIFT+4C6/A8cKDFTRBiArZcKjA36mcx/4G3FsjVkL1Obr2aw7MxhM380ifVzqZPadfUM X198Tu9cOSZmmxevMk+7tctdUJqdad97nCYOVBOuOxsYbbI49+7N2oi0zgvoaXCoZSG2 tVUS7ru4cIAi7LFOquJxNQNS+q7zjey9hWfJC6h1xWvOaTeYiGU1uyycYhV8Y1d0lvsD WV5A==
MIME-Version: 1.0
Received: by 10.180.95.129 with SMTP id dk1mr9964881wib.3.1333048268834; Thu, 29 Mar 2012 12:11:08 -0700 (PDT)
Received: by 10.223.88.212 with HTTP; Thu, 29 Mar 2012 12:11:08 -0700 (PDT)
In-Reply-To: <CAL9jLaYRi1Uj1g1OXVt9O10ZCWWtoCm646fyqGsYrJkJG99HxQ@mail.gmail.com>
References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> <D7A0423E5E193F40BE6E94126930C49308E9E3552F@MBCLUSTER.xchange.nist.gov> <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> <D7A0423E5E193F40BE6E94126930C49308EE1E84C3@MBCLUSTER.xchange.nist.gov> <CAL9jLaYRi1Uj1g1OXVt9O10ZCWWtoCm646fyqGsYrJkJG99HxQ@mail.gmail.com>
Date: Thu, 29 Mar 2012 15:11:08 -0400
Message-ID: <CAH1iCipDYJpWmMpmvdX+Z4AW7cg0QarJbaAmf1JeEBq0rGHiAw@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Content-Type: multipart/alternative; boundary="f46d0444ee2d8847f204bc667cf7"
Cc: Chris Morrow <morrowc@ops-netman.net>, "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "Murphy, Sandra" <Sandra.Murphy@cobham.com>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>, "sidr@ietf.org list" <sidr@ietf.org>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
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: Thu, 29 Mar 2012 19:11:14 -0000

Hang on, and notwithstanding the request for WGLC.

I think the use cases are likely to be informed by protocol design, so even
if they are baked, I'd argue that at best that would be only halfway baked.

I have a few examples that I can think of, which would necessarily depend
significantly on design choices which have been made "by default", but
which may turn out to be poor choices, or where later discoveries could
result in better choices.

I'd prefer this to be added to a "raft" of IDs, for which there is no rush
to publish until they are all completed, after which the timing would be
appropriate.

Here's an example of use-case, which depends on certain assumptions (which
may or may not be appropriate, but which are fodder for discussion):

Suppose there is an Edge-AS "E", and transit providers to "E", which would
be "X" and "Y".

Suppose "E" does not do BGPSEC (per se), but wants to have BGPSEC signing
done "for her", by "X" and "Y".

(Ignore for the moment that the _current_ designs don't support that, that
is an entirely other rat-hole for the moment.)

What "E" would want to do, is have a delegation, controlled by "E", towards
both "X" and "Y" which allow "X" and "Y" to create proxy-path-signatures
and proxy-originations, of "X E" and "Y E" respectively.

This is about origination, is related partly to BGPSEC
requirements/architecture/design/protocol, and necessarily has to do with
RP validation based on ROAs.

It would be, in theory, possible for _either_ X _or_ Y to completely
opaquely proxy for "E", but not for "E" to maintain control, nor to have
both X _and_ Y proxy, transparently or opaquely.

I don't think we need to fully address this use case just yet, but rather
it is an example of something that justifies putting the WGLC on hold, or
at least holding it at immediate-post-WGLC state, for further revision
pending other work on the protocol.

Having decisions based on prior work, rather than informed experience in
deployment, and subsequently locked in, is an example of "bad design"
methodology.

And publishing something IMHO prematurely, locks the WG into that RFC,
making revising it much harder, than if it were still in-WG and
not-yet-published.

(It may turn out to eventually be unchanged, but we should not presuppose
that. This applies not just to this doc, but pretty much all the docs. We
can make progress on them and "freeze" them without publishing them
piece-meal, and I think the WG output would be much better for doing so.)

Brian

On Thu, Mar 29, 2012 at 2:11 PM, Christopher Morrow <morrowc.lists@gmail.com
> wrote:

> Alright, I'll tackle that tomorrow morning.
>
> -chris
> (cochair)
>
> On Fri, Dec 9, 2011 at 9:03 AM, Sriram, Kotikalapudi
> <kotikalapudi.sriram@nist.gov> wrote:
> > Sandy,
> > Chris,
> >
> > The WGLC on this doc ended 09/22/2011.
> > We (the authors) submitted a substantially revised version on October
> 31, 2011,
> > taking into careful consideration all comments that were received during
> the WGLC.
> > Please see Warren's note (attached below).
> > The authors feel that this document is now ripe and ready for wrapping
> up the WGLC.
> > Thanks.
> >
> > Sriram
> > ________________________________________
> > From: Warren Kumari [warren@kumari.net]
> > Sent: Thursday, November 03, 2011 1:06 PM
> > To: Sriram, Kotikalapudi
> > Cc: Warren Kumari; Randy Bush; sidr@ietf.org list
> > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
> >
> > On Oct 31, 2011, at 7:56 PM, Sriram, Kotikalapudi wrote:
> >
> >> In this revised version, we (authors) have made changes with careful
> consideration
> >> of all the comments (mostly of editorial nature) received from Warren
> and Randy.
> >>
> >> http://www.ietf.org/mail-archive/web/sidr/current/msg03349.html
> >> http://www.ietf.org/mail-archive/web/sidr/current/msg03306.html
> >> http://www.ietf.org/mail-archive/web/sidr/current/msg03305.html
> >> http://www.ietf.org/mail-archive/web/sidr/current/msg03304.html
> >>
> >> We have also made many other edits throughout the doc to improve
> >> clarity and readability.
> >
> >
> > Thank you.
> >
> > I support this moving forward (which is just a formality, I supported it
> before as well, this all just makes it (IMO) better)..
> >
> > W
> >
> >>
> >> Sriram
> >> ________________________________________
> >>
> >>        Title           : Use Cases and Interpretation of RPKI Objects
> for Issuers and Relying Parties
> >>        Author(s)       : Terry Manderson
> >>                          Kotikalapudi Sriram
> >>                          Russ White
> >>        Filename        : draft-ietf-sidr-usecases-03.txt
> >>        Pages           : 30
> >>        Date            : 2011-10-31
> >>
> >> A URL for this Internet-Draft is:
> >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-03.txt
> >>
> >
> > _______________________________________________
> > sidr mailing list
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>