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

"Sriram, Kotikalapudi" <> Sat, 31 March 2012 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD6B821F8743 for <>; Sat, 31 Mar 2012 13:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.349
X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GslT5DqXJ1kk for <>; Sat, 31 Mar 2012 13:35:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 97F0D21F871E for <>; Sat, 31 Mar 2012 13:35:33 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 31 Mar 2012 16:35:12 -0400
Received: from ([fe80::d479:3188:aec0:cb66]) by ([]) with mapi; Sat, 31 Mar 2012 16:31:12 -0400
From: "Sriram, Kotikalapudi" <>
To: Brian Dickson <>
Date: Sat, 31 Mar 2012 16:31:12 -0400
Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
Message-ID: <>
References: <> <> <> <> <> <> <> <>, <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Chris Morrow <>, "Murphy, Sandra" <>, " list" <>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 31 Mar 2012 20:35:34 -0000


There is a clear distinction between “prefix-origin validation” (based on ROA information) 
and "origination (signed injection into BGPSEC)" in the SIDR working group's usage of these terms. 
You seem to be attempting to use these two terms with the same connotation. 
Your comments clearly pertain to path signing. You seem to be especially concerned about 
path signing by a stub origin AS or by a proxy AS (e.g., the stub AS's upstream transit provider). 
Draft-ietf-sidr-usecases I-D documents use cases relating only to “prefix-origin validation”.
A use-cases document for the path signing would be a separate document; 
as far as I know no one is working on it at the moment. 
So your comments seem misplaced, i.e., they appear not relevant to draft-ietf-sidr-usecases. 
Please also see my response in my other post that follows this post, but with the subject:
stub AS and proxy signing. 
Thank you.


> To: Brian Dickson <brian.peter.dickson at>
> Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
> From: "Murphy, Sandra" <Sandra.Murphy at>
> Date: Sat, 31 Mar 2012 04:12:10 +0000
> speaking as regular ol' member
> I'm not really sure what you are talking about here.
> You speak of bgpsec and signing - that is not origin validation, that
> is path validation.
> Origin validation is strictly and only judging whether the origin has
> the authority to originate announcements of the prefix.  Origin
> validation does not ensure that the authorized AS is actually making
> the announcement.
> It is bgpsec path validation that ensures that the announcement is
> currently and authentically being announced by the AS.  That's the
> "signed injection" you mention.
> --Sandy
> From: Brian Dickson [brian.peter.dickson at]
> Sent: Friday, March 30, 2012 8:55 AM
> To: Murphy, Sandra
> Cc: Christopher Morrow; Sriram, Kotikalapudi; Chris Morrow; sidr at
> list
> Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
> 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 at
>> 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 at [christopher.morrow at
>] on behalf of Christopher Morrow [morrowc.lists at
> Sent: Thursday, March 29, 2012 7:21 PM
> To: Brian Dickson
> On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson
> <brian.peter.dickson at> 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:
>  <>
> 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