Re: [sidr] stub AS and proxy signing

"Sriram, Kotikalapudi" <> Sat, 31 March 2012 22:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6395F21F8694 for <>; Sat, 31 Mar 2012 15:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.391
X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k8TSMwW+I0uf for <>; Sat, 31 Mar 2012 15:30:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4FA5E21F8685 for <>; Sat, 31 Mar 2012 15:30:57 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 31 Mar 2012 18:30:45 -0400
Received: from ([fe80::d479:3188:aec0:cb66]) by ([]) with mapi; Sat, 31 Mar 2012 18:26:36 -0400
From: "Sriram, Kotikalapudi" <>
To: Brian Dickson <>
Date: Sat, 31 Mar 2012 18:26:35 -0400
Thread-Topic: stub AS and proxy signing
Thread-Index: AQHND4IwlHQhAkmrCky/DL61Gg8hLpaE703m
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
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 22:30:58 -0000


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