Re: [sidr] stub AS and proxy signing

"Sriram, Kotikalapudi" <> Sat, 31 March 2012 21:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18DDE21F8741 for <>; Sat, 31 Mar 2012 14:34:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.372
X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s2jWcb+G-Ub6 for <>; Sat, 31 Mar 2012 14:34:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9F75521F8746 for <>; Sat, 31 Mar 2012 14:34:51 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 31 Mar 2012 17:34:39 -0400
Received: from ([fe80::d479:3188:aec0:cb66]) by ([]) with mapi; Sat, 31 Mar 2012 17:34:50 -0400
From: "Sriram, Kotikalapudi" <>
To: Brian Dickson <>
Date: Sat, 31 Mar 2012 17:30:30 -0400
Thread-Topic: stub AS and proxy signing
Thread-Index: AQHND4IwlHQhAkmrCky/DL61Gg8hLg==
Message-ID: <>
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] stub AS and proxy signing
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 21:34:53 -0000


I hope you agree with me and Sandy that your questions (in the thread re: draft-ietf-sidr-usecases-03) 
were really about proxy signing for the stub origin AS, and not about use cases for 
“prefix-origin validation”. 
That is why I have started this different thread (with changed subject line). 

The author team (and contributors) of draft-ietf-sidr-bgpsec-protocol document discussed
stub ASs and proxy signing by transit provider (upstream AS) at length, and those discussions 
are documented in:
Please see sections 6.5 and 6.6.

Also, please see Section 6 (Considerations for Edge Sites) in the bgpsec-ops document
“Thus a
   smallish edge router may hold only its own signing key(s) and sign
   it's announcement but not receive signed announcements and therefore
   not need to deal with the majority of the RPKI.”

Sharing the stub’s private key with the upstream transit provider is considered a bad practice.
Instead, the stub can simply only sign its prefix(es) to the upstream AS and
receive only unsigned updates from that upstream AS. 
This requires minimal SW upgrade, and no HW upgrade in stub ASs.  

I hope this helps address your questions.


> 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