Re: soBGP deployment

[Tony Li <tony.li () tony li>]

Daniel,

Well, I wish I could have been part of the discussions that you had, as
what you report is at variance with what I've heard.

Fundamentally, there is a serious scalability issue with doing
everything at configuration generation time.  Since one cannot predict
with certainty what AS paths will be seen for which prefix, one would
have to authenticate each and every possible path and then encode the
authenticated paths in the configuration.

I am very sensitive to the plight of operators and do understand the
need to preserve BGP stability.  However, I think that there are
alternative approaches that can provide such stability during deployment
while remaining dynamic.

For example, an operator can begin by enabling authentication on a BGP
speaker that is wholly outside of the traffic path.  Instability of this
one speaker would have no effect on production traffic.  Authentication
alarms generated by this speaker could be set up to do nothing more than
send a syslog message to operations personnel who would need to
intervene manually to actually change production BGP path selection.
For testing authentication, a host behind this speaker could monitor
reachability.

I'm hopeful that this type of approach is a reasonable compromise
between operational needs of stability and the actual dynamic
near-real-time authentication computations that need to occur for these
solutions to be effective.  I welcome feedback from those concerned,
publically or privately.

Regards,
Tony


> > From discussions with large operators during NANOG week it is clear to
> me that at this point most will simply not deploy anything that
> dynamically interacts with their inter-domain routing (BGP).  All are
> comforatble with deploying something that works via the current
> mechanism of periodically built configurations.  In fact most said to
> wait for something that would take some of the heuristics out of that
> process.  We will not get any deployment unless either that attitude
> changes or we engineer taking it into account.  I prefer the latter. 
>
> To me the first stage of any deployment becomes obvious then:
> Map the fucntionality of s*BGP into tools to build routing configurations
> from signed information distributed by whatever means. This will make rapid
> deployment possible with a high comfort level for operators which is key!
> It would bring immediate benefits and help us build and understand the 
> databases that are necessary. In parallel we can develop more dynamic
> ways of distributing the information and interacting with BGP.
> If the design and trust model of s*BGP is indeed well conceived this
> will be attractive enough for operators to see deployment.
>
> Note that I am not advocating routing registries. I agree with those that
> consider them a failure although I have been a long time supporter.
> The idea is to start building the (signed) meta-information and using it
> as additional input to the configuration generation already done by operators.
> Ideally this would quickly obsolete from routing registries and many heuristics.
>
> Can such a first step of an incremental deployment be designed for any of s*BGP?
>
> Daniel