On Fri, Feb 11, 2011 at 11:41 AM, Tony Tauber <[email protected]> wrote: > I'm also wondering on which provider routers Randy's seeing the need for > crypto and other HW upgrades. > If it's every router that carries full routes or terminates an external BGP > session, that can be a pretty big nut to swallow.
if this happens in the normal course of upgrades, over the next 4-7 years... is it still a big deal? > Why don't we work on getting someone on board with a working something > before getting down the garden path which leads people to throw up their > hands about non-starters and stuff. > > Tony > > On Fri, Feb 11, 2011 at 10:51 AM, Shane Amante <[email protected]> > wrote: >> >> 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. >> >> Whoa there. I couldn't disagree more wrt the above. >> >> 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. >> 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 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 > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
