I would guess you would get a very low take rate on "secure bgp" even if you gave it away (no premium). It would be interesting to see how many customers implemented MD5 for bgp peering sessions when it became freely available. It wasn't very widely deployed the last time I heard. It got a ton of push back on the NANOG list when I recommended it.
Ignorance is Bliss. "Bliss (Basic Language for Implementation of System Software) was a systems programming language originally for the PDP-10 and DECsystem-20 written at CMU." Kevin Oberman RTD [email protected] > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Jakob Heitz > Sent: Wednesday, September 07, 2011 7:13 AM > To: Rob Shakir > Cc: sidr wg list > Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) > > 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 This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
