Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
Christopher Morrow <morrowc.lists@gmail.com> Thu, 29 March 2012 23:21 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 7F2D621F8534 for <sidr@ietfa.amsl.com>; Thu, 29 Mar 2012 16:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.564
X-Spam-Level:
X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 K5xNmdFyLp1v for <sidr@ietfa.amsl.com>; Thu, 29 Mar 2012 16:21:06 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1578B21F8531 for <sidr@ietf.org>; Thu, 29 Mar 2012 16:21:05 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so36217ggm.31 for <sidr@ietf.org>; Thu, 29 Mar 2012 16:21:05 -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; bh=hLu3bQNjkxaY1S5wAaPxx41j7xN9h2vnWgZiV2nR2/U=; b=WJlq+orZyWetx4U78mlZUSrg0WuNn2IpFOjVIu8SI3451pUArIjar6nqQVE60qHVYC PjmFpLSfqruki88cBkW7Go+mTh8WSjGbZHKNtmWvlJS3DBi/7fRMyubngUANVc7L4Rgv YOmoxErtCDdwVSv6DpfrfKSrASwHMtLi6UbODpZX/GOSsBAxl4a7jaQjkBm9cGilQwcD iEVvmXZLMSYSpiJnNDZRJaJsQQYsROP/zJOJ8xqYIzLTfcEGFLxlgggomSVxTP7L5L/a GrY17tWKCy3701atZgG0uVlqQr7Kn9irSGQkHD52zQ8Do44nv/aD3r8pERYPpczec8SJ 6RTg==
MIME-Version: 1.0
Received: by 10.60.9.38 with SMTP id w6mr23289oea.41.1333063265299; Thu, 29 Mar 2012 16:21:05 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.80.137 with HTTP; Thu, 29 Mar 2012 16:21:05 -0700 (PDT)
In-Reply-To: <CAH1iCipDYJpWmMpmvdX+Z4AW7cg0QarJbaAmf1JeEBq0rGHiAw@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> <CAH1iCipDYJpWmMpmvdX+Z4AW7cg0QarJbaAmf1JeEBq0rGHiAw@mail.gmail.com>
Date: Thu, 29 Mar 2012 19:21:05 -0400
X-Google-Sender-Auth: bibpxDGDw67qjjoFD0h06_vHO00
Message-ID: <CAL9jLaaZ2z+WfXJCgaa2ob71t4Qk_khC12UZrr8XT9OzCEs8FA@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
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 23:21:07 -0000
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