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.
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
