(coffee != sleep) & (!coffee == sleep) [email protected] gcia
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Shane Amante > Sent: Friday, February 11, 2011 8:51 AM > To: Randy Bush > Cc: [email protected]; Russ White > Subject: Re: [sidr] bgpsec-reqs-00 > > Randy, > > On Jan 30, 2011, at 20:40 MST, Randy Bush wrote: > >> 3.3 As cryptographic payloads and loading on routers are likely to > >> seriously increase, a BGPsec design may require use of new > hardware. > >> It must be possible to build routers that do BGPsec with within > >> acceptable (to operators) bounds of cost and performance. > >> > >> This should be left out of any requirements document, and various > >> proposed system compared based on their costs and deployment > >> difficulty. > > > > i take your point. the intent was that compatibility with current > > hardware abilities is not a requirement that this document > imposes on a > > solution. it is quite likely that provider routers will need crypto > > assist and more ram. though one hope that the stub > customer edge will > > not. Adding crypto engines and more ram is going to be expensive not just from a hardware pov but from power and heat. We (ISPs) budget those items too. If all of my routers suddenly needed 20% more of either of those its going to affect our bottom line (cost of transport goes up):) > > Whoa there. I couldn't disagree more wrt the above. I could disagree more but Shane does a pretty good job here of stating why this is an issue. (thanks Shane). > > First, let's start with the most fundamental question. Why > is it that routers MUST sign, pass around and verify > _in-band_ in the control plane various contents/PDU's > _within_ BGP? Note my very careful use of the work > _in-band_. By that I mean inside the BGP session itself, not > on a side-band channel like RPKI and/or IRR is used today. > While I have grave concerns over in-band signing & > verification, I am [much] less concerned about the latter for > several reasons. With respect to in-band: > 1) I'm extremely concerned over dependencies of > automatically "trusting" signed data in-band within the > control plane and not being able to reach servers (RP's?) to > verify the contents of the PDU's are legitimate. At least > with prefix-filters and/or AS_PATH filters, it's very easy > for me to manually disable some or all filtering for > particular destinations in order to, say, get reachability to > servers (RP's) to verify the authenticity of data. Route filters in many ISPs are created and validated nightly and pushed to routers if a filter change is needed. That isn't usually done in real time. It is almost always done on COTS hardware (not on the router it's self). > 2) Related to point #1, we really should go back to first > principles ask ourselves if we're really intending to > conflate the _transport_ method (BGP) with the requirement to > verify the data _inside_ of BGP. If so, what is the reason? > Is it solely for convenience, (because BGP transport is > already there), or other reasons? > 3) I really, really don't like the idea of "will need crypto > assist and more ram" on my RE/RP's for several reasons, namely: > a) It's one more set of variables that my already > over-worked Capacity Planning and NOC groups need to keep > track of and attempt to stay ahead of. > b) It's extremely costly to upgrade RE/RP's, because > said RE/RP's are only available from one source -- equipment > vendors. And, the upgrade paths typically don't buy you much > in terms of more CPU, etc., because vendors are obligated to > source "established" components they know they'll be able to > acquire for several years into the future. And, worst of > all, the cycle to get those RE/RP's into the network is > extremely long when you start to consider the budgeting, > testing of new code, physical installation, customer > disruption during maintenance windows, etc. > ... at least with respect to (b), if I were able to use > offboard CPU (i.e.: Intel/AMD servers, like in the RPKI/IRR > world), then I have a much larger selection of HW to choose exactly! > from and I can upgrade those in the network much, much more quickly. > > At least with respect to #1 and #2, I don't see any > discussion of the above in the current draft (although maybe > I missed it?). But, IMHO, those are _fundamental_ > requirements that need to be discussed among the WG. Before > touching on any of the other points in Russ White's e-mails > in this thread, (which I agree with), I think it's important > to get back to basics. > > > > and the operators with whom we discussed (note that i am an > operator, > > not a vendor with a bad habit of speaking for operators) > this thought > > that this needed to be said from both ends of the scale. we did not > > want the future security constrained by a 7200, nor did we want an > > explosion in costs. as dollars are the bottom line in our > capitalist > > culture, constraining them seems quite reasonable. > > It wasn't discussed with me. :-) > > -shane > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > This communication is the property of Qwest 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
