Subject: Re: [sidr] stub AS and proxy signing

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sat, 31 Mar 2012 17:30:30 -0400

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

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sat, 31 Mar 2012 18:26:35 -0400

Brian,

I am addressing your new questions (which still are about stub AS and proxy signing) under the new thread. 

>It is all fine and well to do origin-validation based on BGP origination, but since the 
>current design of bgpsec is anchored to (vanilla, non-sec) BGP origination as well, 
>this means identifying affected elements when challenging the bgpsec design.

The design of BGPSEC assumes that all participating ASs are BGPSEC capable.
The stub AS is assumed (required) at the minimum to be capable of signing 
the prefix(es) it originates. Vanilla, non-sec stub ASs are not part of BGPSEC islands.
They join BGPSEC islands when they make an arrangement with their upstream at least 
to sign towards them even though they may agree to receive only unsigned 
updates from their upstream. 

>And, what I'm suggesting is, that restricting bgpsec deployment to only origin AS 
>operators who deploy bgpsec (i.e. excluding proxy injection into bgpsec from 
>non-bgpsec origins), is not something the operator
>community is likely to accept with open arms.

If a stub AS operator trusts the upstream transit provider and hands her private key
to the upstream AS operator, that cannot be ruled out since it is a private arrangement.
But the BGPSEC protocol need not specify the same (i.e., arrangement of proxy injection) 
as it can always be done by consenting parties.

>There are too many edge ASNs today, using too many vendors' equipment 
>with too many varieties of equipment within vendors, and too varied code base, 
>to believe rapid uptake or critical mass is feasible 
>in the timeline the WG participants might like to believe.

Interestingly,  the same arguments that you use above were used to include support for 
simplex BGPSEC in the design for accommodating stub ASs (the small, not very resourceful AS operator).
Again, quoting from bgpsec-ops document:

Section 6.  Considerations for Edge Sites

   An edge site which does not provide transit and trusts its
   upstream(s) SHOULD only originate a signed prefix announcement and
   need not validate received announcements.

   BGPsec protocol capability negotiation provides for a speaker signing
   the data it sends but being unable to accept signed data.  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.

   As the vast majority (84%) of ASs are stubs, and they announce the
   majority of prefixes, this allows for simpler and cheaper early
   incremental deployment.  It may also mean that edge sites concerned
   with routing security will be attracted to upstreams which support
   BGPsec.

Sriram