On 11 Aug 2011, at 22:40, George, Wesley wrote: > Danny said, > "Periodic updates of the entire routing table *with much larger and more > updates* seems undesirable at best to me, particularly to 'reduce the > vulnerability window for replay attacks' to 'days'." > --------------------------------------------------------- > I think that this is a small part of a much larger issue that has been > bugging me since our meeting in Quebec City. > After looking at Sriram's estimates around the necessary amount of memory, > etc for the different algorithms, I'm bothered by what is being asked of the > routing system in support of BGPSec. >
Hi All, Wes' point here is really important I think, and it's a bit of a shame it hasn't got more focus. I stood up and mentioned scaling in Prague, then found myself making a very similar point again in Québec. As with Wes, I would prefer that this is not interpreted as a criticism of the goals of bgpsec, but rather is an operational perspective on the assumptions that are made for deployment of the protocols being developed in sidr. The root assumption that we seem to be taking as read throughout such discussions is that at the point where routing infrastructure is expected to support the computational load that is demanded of it by bgpsec, there will have been sufficient growth in both the computational and memory resources that are available to these systems. Whilst I appreciate that cryptographic validation of the validity of a route can be performed on the edge system(s), I think there are two very key concerns here. - Historically, do we see Internet routing systems matching the rate of general computational resource availability? My view on this is that we do not - there are plenty of edge systems out there that are relatively modern (and capable of routing tens of gigabits of traffic) that do not have a control-plane that is as powerful as some of the software devices that existed prior to it - as such, this means either this was a lower priority to deliver (which may well be true), or that it was not practical to do so. With increasing demands on control-plane resources of IP systems (be they Internet edge or otherwise) - there is surely some query as to whether having a large amount of memory or crypto offload hardware will be a priority over other features. The question Wes raised as to whether we, as a working-group, are happy with the assumption that this is the case, is very valid. It would seem to me that we are being somewhat prescriptive with prioritising what hardware vendors' solutions should look like, and what operator's scaling approaches will look like - without necessarily explicitly discussing why this is reasonable to do so. - Are the assumptions that we are making regarding how those autonomous systems delivering an "Internet" product set are architected valid? There is some assumption (AIUI, please feel free to correct me) that we are looking at networks where we have explicit edge devices which can scale to meet the validation workload that we're putting on it. This would seem (again, to me) to be based around assumption that there are a relatively high number of less-dense edge devices. I would be interested whether it's the feeling of the WG that my reading of what we're assuming is correct - and if so, whether the WG feels that we can be prescriptive like this for how one should architect an Internet network. I'm again very supportive of what problems bgpsec is trying to solve - and do not want to put a dampener on any of the excellent efforts that have gone into it - but think that we cannot wholly abstract ourselves away from the actual deployability of the solutions that are being developed. After all, we will not solve the problems that the WG is chartered to solve if the fruits of the labours herein are not actually deployed. I am not sure of exactly how we progress discussing the scalability of the solution - but with Sriram's analysis, is it possible to discuss within this forum, and perhaps others concerned with the general scaling of IP routing elements, why the scaling considerations/assumptions of bgpsec are valid, and where a departure is made from the longer term view of scalability that is presented in existing IETF documents. Thanks for reading this - and your consideration! r. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
