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

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 30 March 2012 14:34 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 82DB121F86D1 for <sidr@ietfa.amsl.com>; Fri, 30 Mar 2012 07:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.565
X-Spam-Level:
X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, 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 iMc7wahn424x for <sidr@ietfa.amsl.com>; Fri, 30 Mar 2012 07:34:38 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2D81F21F864B for <sidr@ietf.org>; Fri, 30 Mar 2012 07:34:38 -0700 (PDT)
Received: by wibhr17 with SMTP id hr17so737634wib.1 for <sidr@ietf.org>; Fri, 30 Mar 2012 07:34:37 -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=do8yBq9afdsrqj0JKtXVAMeL6/eIyA4WWBlQHC68VWo=; b=ijltVVXUrlvQcvWaJu7rWWPEs/ADIQYmvonnqfg0NG+Z3oAHxpCVmFZSKDpeq+c6uF ujLu0cRvsjifjAu3x2lkKCr2FBjZPSoU8RVdLUoGW6gIliNNeVeLT4wKnZoNNDRnvlH/ sKD5JLUeXaulxo4qJqde/g2l1n56HWeE2cJ+FfQWkaeIcNJx/PVfVjq3yhnnxb0pMXgZ JidS6sSL14seATdFT+EuBfmcMrG7dKJDmVAIikHIADU3tGhN/7BzYE8nvK+S3r/VGaXI 9HMQE6iK+7dZfH/DubdmWJqdc4MTNSnQXovJLyJZRgBZF3jJM4JwvOqxLcYlg8ppBbs7 vqKw==
MIME-Version: 1.0
Received: by 10.180.107.101 with SMTP id hb5mr7324226wib.3.1333112139427; Fri, 30 Mar 2012 05:55:39 -0700 (PDT)
Received: by 10.223.88.212 with HTTP; Fri, 30 Mar 2012 05:55:39 -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 08:55:39 -0400
Message-ID: <CAH1iCiqk4cgPwQGi4751mZCNes2J4B6z7BeRJ0AD0+An8M_DNg@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
Content-Type: multipart/alternative; boundary="e89a8f3bb0cf84311504bc755b4b"
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 14:34:46 -0000

Sandy,

The use case example I included, is an origin validation use case.

The problem is the inability to have "origination" (signed injection into
BGPSEC) done by proxy, at all or especially by more than one party.

The particular situation leading to the need for this, would be a stub AS
whose router vendor does not support BGPSEC, or whose router hardware or
code base is not included in BGPSEC support by their router vendor.

(Doing a forklift upgrade to do BGPSEC is generally seen as #FAIL by
operators.)

This is likely to be a fairly common situation _among stub AS_ and, given
the current requirement for origin injection for BGPSEC, addressing this
_may_ impact the use cases document, for _origin validation_.

I'm just saying...

Brian

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