Re: [sidr] stub AS and proxy signing

["Sriram, Kotikalapudi" <[e-mail]>]

Brian,

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:
http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01
Please see sections 6.5 and 6.6.

Also, please see Section 6 (Considerations for Edge Sites) in the bgpsec-ops document
http://tools.ietf.org/html/draft-ymbk-bgpsec-ops-01
“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.

Sriram

> From: Brian Dickson [brian.peter.dickson at gmail.com]
> Sent: Friday, March 30, 2012 8:55 AM
> To: Murphy, Sandra
> Cc: Christopher Morrow; Sriram, Kotikalapudi; Chris Morrow; sidr at
> ietf.org 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