Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
Christopher Morrow <morrowc.lists@gmail.com> Fri, 30 March 2012 09:45 UTC
Return-Path: <christopher.morrow@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 30B2F21F8878 for <sidr@ietfa.amsl.com>; Fri, 30 Mar 2012 02:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.565
X-Spam-Level:
X-Spam-Status: No, score=-103.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 mGhw73JQVmhM for <sidr@ietfa.amsl.com>; Fri, 30 Mar 2012 02:45:04 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75E2121F8888 for <sidr@ietf.org>; Fri, 30 Mar 2012 02:45:04 -0700 (PDT)
Received: by obbta17 with SMTP id ta17so871207obb.31 for <sidr@ietf.org>; Fri, 30 Mar 2012 02:45:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=87ewRruSWAke85ihqh4V8Cx8mBtCkLIYvfG0FwyMjfA=; b=W5/w54YNMna7HfiBq3MDFUxoZgGulhzV2QqrEdRA1azjee7ehtQkcvKSondC913apS H4rZ3MJp962Rt41lg8JTCNXAVwGbwq29efnAaP/16xq7nWxL8GnsfqXNUG6vFs6TOyGO r/9ioiGv310sMSPBEE0jmnQGX8URFRDBpnJCAue4puvF0dinu7m5RJj8EcfhxqpIdzNa QRLLn7YNFE+PlZSX/Zy3Ql3uuVkmKPWWala85m2PeRp/0ypFrFGqPBLnjgqY2wZL3OvJ alKbnLc+A+6b/hR8xYfgHRxqRDzux20Ztd/+yntJkeHUId9Vq6+7Grug1xIf+QPnQA3s 9GcA==
MIME-Version: 1.0
Received: by 10.182.85.39 with SMTP id e7mr1697248obz.51.1333100704101; Fri, 30 Mar 2012 02:45:04 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.80.137 with HTTP; Fri, 30 Mar 2012 02:45:04 -0700 (PDT)
In-Reply-To: <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> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0391@Hermes.columbia.ads.sparta.com>
Date: Fri, 30 Mar 2012 05:45:04 -0400
X-Google-Sender-Auth: LIBeKnG3PmNueWMOqxz3-7nP5tY
Message-ID: <CAL9jLabAMBk+qB4WvHThmDLkNWpEQ6Gj=zQiSMZgaWxDq9G8Cw@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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 09:45:05 -0000
On Fri, Mar 30, 2012 at 4:21 AM, Murphy, Sandra <Sandra.Murphy@sparta.com> wrote: > 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. fair enough. (it seems to me) > --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
- [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt internet-drafts
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Sriram, Kotikalapudi
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Warren Kumari
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Sriram, Kotikalapudi
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Christopher Morrow
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Brian Dickson
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Christopher Morrow
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Murphy, Sandra
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Christopher Morrow
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Brian Dickson
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Murphy, Sandra
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Sriram, Kotikalapudi
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Brian Dickson
- Re: [sidr] I-D Action: draft-ietf-sidr-usecases-0… Danny McPherson