While a router that performs BGPSEC may not be more expensive in 5 years than one that does not today, that is not relevant. A router that performs BGPSEC in 5 years will most definitely cost more to produce as well as cost more to run than a router that does not perform BGPSEC in 5 years.
So, a question for you Rob. Will your customers pay the premium for BGP security? -- Jakob Heitz. On Sep 7, 2011, at 5:05 AM, "Rob Shakir" <[email protected]> wrote: > 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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
