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