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