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

"Murphy, Sandra" <Sandra.Murphy@sparta.com> Fri, 30 March 2012 08:21 UTC

Return-Path: <Sandra.Murphy@sparta.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 C7F5421F882C for <sidr@ietfa.amsl.com>; Fri, 30 Mar 2012 01:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.47
X-Spam-Level:
X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, 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 l9fjTKIzJhWz for <sidr@ietfa.amsl.com>; Fri, 30 Mar 2012 01:21:50 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3419221F8822 for <sidr@ietf.org>; Fri, 30 Mar 2012 01:21:50 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2U8Lmih011716; Fri, 30 Mar 2012 03:21:48 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2U8Ll5v003225; Fri, 30 Mar 2012 03:21:47 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Fri, 30 Mar 2012 04:21:47 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: Christopher Morrow <morrowc.lists@gmail.com>, Brian Dickson <brian.peter.dickson@gmail.com>
Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
Thread-Index: AQHMmCOt1CW4b+qPEkuJdphkZ9jq2pWXZE2AgAREVgCAOHGKgICup3EAgAAQjACAAEXWgIAAU6pD
Date: Fri, 30 Mar 2012 08:21:46 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0391@Hermes.columbia.ads.sparta.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> <CAH1iCipDYJpWmMpmvdX+Z4AW7cg0QarJbaAmf1JeEBq0rGHiAw@mail.gmail.com>, <CAL9jLaaZ2z+WfXJCgaa2ob71t4Qk_khC12UZrr8XT9OzCEs8FA@mail.gmail.com>
In-Reply-To: <CAL9jLaaZ2z+WfXJCgaa2ob71t4Qk_khC12UZrr8XT9OzCEs8FA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.185.63.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Chris Morrow <morrowc@ops-netman.net>, "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: Fri, 30 Mar 2012 08:21:52 -0000

Brian, Chris.

The usecases draft was intended to describe origin validation use cases.

Route leaks (and other path validation issues) might need their own usecases draft.

But I don't think we should add those cases to this draft.

--Sandy

________________________________________
From: christopher.morrow@gmail.com [christopher.morrow@gmail.com] on behalf of Christopher Morrow [morrowc.lists@gmail.com]
Sent: Thursday, March 29, 2012 7:21 PM
To: Brian Dickson
Cc: Sriram, Kotikalapudi; Chris Morrow; Murphy, Sandra; Murphy, Sandra; sidr@ietf.org list
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt

On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson
<brian.peter.dickson@gmail.com> wrote:

> I think the use cases are likely to be informed by protocol design, so even

s/informed by protocol design/altered if the protocol design changes/

I'm not sure if the protocol design's going to change the use-cases...
you're still going to want to secure a route. (not an important point)

> I have a few examples that I can think of, which would necessarily depend
<snip>
> 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.

I'm not against this, though we've got a document hanging out post
WGLC (perhaps it ought to be re-reviewed if the changes were
significant... anyway) and we'll have to keep kicking it each 5.5
months to stay 'alive'. (again, not super important, and see below as
well)

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

hrm, in:

  <http://tools.ietf.org/id/draft-ietf-sidr-bgpsec-ops-04.txt>

section-6 there's discussion of 'only sign your one prefix, do nothing
else complex' which fits the model, albeit requiring the end site to
run some small number of commands on their device. If they wanted to
hand their private key materials to the upstreams they could do the
signing, but that seems icky (to me).

I don't know that, if implications are understood by the end site and
configurations available for use on their side, end-sites would want
to hand over control of their IP assets in this way. Running the
signing on their side should be simple enough, and low/no-cost.

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

I think the authors said something like: "send text" where you think
it is fit to be inserted... If other folks want to delay/re-review
they need to speak up. Consensus so far was that the document was
ready to move along.

-chris